Added an enum with the mouse event options for `fire_mouse_event` and refactored the `event_name` parameter to take the enum as argument.
I also added two options (Leave and Enter) which are noted as todo in the comments.
- [x] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These Changes fix#18943.
- [X] These changes do not require tests because the issue said a clean build suffices.
Source-Repo: https://github.com/servo/servo
Source-Revision: 1b08bfc5c0f49dabf205c9f3c32d35c21ea0042c
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : fddb81c95d0bdae59595e873b5577378c6903b15
This addresses a paint point when using debug-mozjs builds. jonco says that it is considered a leak when objects stored in side tables in a SpiderMonkey embedding are traced right before shutting down. This PR adds a per-thread flag that controls whether to run the Rust-side trace hooks, which is automatically toggled before the final GC occurs when destroying a JS runtime.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#18948 and fix#18947.
- [x] These changes do not require tests because we don't use debug-mozjs on CI
Source-Repo: https://github.com/servo/servo
Source-Revision: a71470abe5b8b4b5c14183c6e8bf7e4eefd5c5a7
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : dc746c0d0ac83d7c5a7dc7dc43001c9af0257b00
If this doesn't match with the size it's more likely for anything caught
t be hardware corruption. If it does the situation is more interesting.
Source-Repo: https://github.com/servo/servo
Source-Revision: ba9af5c124935734437b9258c3bdb5fee1e487a0
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 23fdab8eaae62883df3d3a42a5b120c1e46dbb64
The %c marker is only valid for the first argument, so if we find ourselves
between two parameters with user-styled messages, it means we should respect
the original formatting.
MozReview-Commit-ID: 4GORZyvvxRN
--HG--
extra : rebase_source : 11adda5e3a18a7e52a02bdbcf1a18a5bfee6ee2c
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
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
Check background attribute values for the same types (URL, image) in Stylo mode
as we do in Gecko mode.
In particular, this ignores the edge case of the empty attribute, which comes
through as a string value type, and leads Stylo to trigger a load of the page
itself as the background image (since the empty URL is interpreted as relative
to the page).
MozReview-Commit-ID: CUhq5nS8kVw
--HG--
extra : rebase_source : 8a04a3175cb1a873ee7e597ad881ae64720c01ef
