Summary:
With both managers storing transaction infos in `Maybe<Info> mTransaction` now,
it occurred to me that we can't actually assert that
`mTransaction.isSome() == true` when we receive a message.
At least with the U2F API the request could be cancelled (and mTransaction
cleared) while there's a pending completion message. For WebAuthn it probably
doesn't hurt to handle this properly either.
(As a bonus, I snuck in the removal of an unused enum.)
Reviewers: jcj
Reviewed By: jcj
Bug #: 1410428
Differential Revision: https://phabricator.services.mozilla.com/D145
Summary:
This patch aims to clean up the U2FManager's state machine, especially to make
cancellation of transactions clearer. To fix bug 1403818, we'll have to later
introduce a unique id that is forwarded to the U2FTokenManager.
There are multiple stages of cancellation/cleanup after a transaction was
started. All of the places where we previously called Cancel() or
MaybeClearTransaction() are listed below:
[stage 1] ClearTransaction
This is the most basic stage, we only clean up what information we have about
the current transaction. This means that the request was completed successfully.
It is used at the end of FinishRegister() and FinishSign().
[stage 2] RejectTransaction
The second stage will reject the transaction promise we returned to the caller.
Then it will call ClearTransaction, i.e. stage 1. It is used when one of the
two Finish*() functions aborts before completion, or when the parent process
sends a RequestAborted message.
[stage 2b] MaybeRejectTransaction
This is the same as stage 2, but will only run if there's an active transaction.
It is used by ~U2FManager() to reject and clean up when we the manager goes
away.
[stage 3] CancelTransaction
The third stage sends a "Cancel" message to the parent process before rejecting
the transaction promise (stage 2) and cleaning up (stage 1). It's used by
HandleEvent(), i.e. the document becomes inactive.
[stage 3b] MaybeCancelTransaction
This is the same as stage 3, but will only run if there's an active transaction.
It is used at the top of Register() and Sign() so that any active transaction
is cancelled before we handle a new request. It's also used by U2F::Cancel()
as long as bug 1410346 isn't fixed.
Reviewers: jcj
Reviewed By: jcj
Bug #: 1410345
Differential Revision: https://phabricator.services.mozilla.com/D144
Since it's timing out very frequently on central, and apparently the culprit is
bug 1409088, which just added a relatively expensive assertion in layout.
Since that assertion has caught at least two bugs already since it landed, I
really don't want to remove it...
MozReview-Commit-ID: JVeAVKZe1PE
This fixes a regression from bug 1408365. Ideally these imports would
be defined at the top of the file, then the py2 linter would have caught
them. Even more ideally, mozboot would have some tests that hit these
code paths.
MozReview-Commit-ID: BWvIwAdUBF4
--HG--
extra : rebase_source : 6472f730a5cd12aa98af7a21f958d1ad2400f995
This is the servo side of bug 1403213.
This cannot merge until https://bugzilla.mozilla.org/show_bug.cgi?id=1377351 merges. It is currently on inbound. This will break autoland when it merges until the gecko-side part has also landed.
Source-Repo: https://github.com/servo/servo
Source-Revision: 7e0f5afa83d9f0eba07988735e56f47a2c18b451
--HG--
rename : servo/components/style/gecko_bindings/nsstring_vendor/src/lib.rs => servo/support/gecko/nsstring/src/lib.rs
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : ee57178ea85a844d5fb5c15e9aab3d430c0ac9a1
It appears that in this case just waiting for the APZ flush to complete was
insufficient, probably because the APZ flush and touch inputs go via different
IPC channels and therefore do not provide ordering guarantees. So instead of
waiting for the APZ flush, let's just wait until the touchstart is received
in the content process and use that to resume the test.
MozReview-Commit-ID: AcPRhox1Xkg
--HG--
extra : rebase_source : be6653c7835d9a61bdc215266367adcc8adf8f0b
