[Gecko Bug 1931692] Make MouseEvent::DuplicatePrivateData() keep storing `mPresContext
#49822
+156
−0
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
wpt-pr-bot
approved these changes
Dec 23, 2024
Currently, `offsetX` and `offsetY` are defined by CSSOM spec [1]. The spec defines that when the event is not being dispatched, these values should be same as `pageX` and `pageY`. However, we started computing the values with the latest data since bug 1203404 for compatibility with the other browsers. However, the test does not check the trusted event behavior. When the event is a trusted event, `Event::DuplicatePrivateData()` clears `Event::mPresContext`. Then, calling `Event::GetOffsetCoords` with specifying `mPresContext` aborts to compute it [2]. Therefore, our mouse events return `0` for `offsetX` and `offsetY` after propagation. Blink and WebKit caches `offsetX` and `offsetY` values when they are referred first time [3][4]. Therefore, their values depend on **when** they are referred. I don't think we should follow their tricky behavior immediately. However, at least, we should return same computed result until the layout and scroll position are not changed. Therefore, this patch makes `MouseEvent` keeps storing `mPresContext` even after calling `UIEvent::DuplicatePrivateData()` and use it when calling `Event::GetOffsetCoords`. Finally, this adds a WPT under `uievents` to check current behavior in the simplest case (i.e., neither scroll position nor layout is not changed after starting the propagation). 1. https://drafts.csswg.org/cssom-view/#extensions-to-the-mouseevent-interface 2. https://searchfox.org/mozilla-central/rev/2493c256dbff4e3c7e51a7fc61115df887b87e9e/dom/events/Event.cpp#707-708 3. https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/events/mouse_event.cc;l=518;drc=0aa8c88324c762d0907de203da053c4545c4fd6b 4. https://searchfox.org/wubkat/rev/d46c14cf9008c4385cf0ac7919561b278d047e85/Source/WebCore/dom/MouseRelatedEvent.cpp#220 Differential Revision: https://phabricator.services.mozilla.com/D232589 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1931692 gecko-commit: cfb7d95a6f12643d327dd20e324c1747219d718b gecko-reviewers: smaug
moz-wptsync-bot
force-pushed
the
gecko/1931692
branch
from
a333977 to
30a8cf8
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently,
offsetXandoffsetYare defined by CSSOM spec [1]. The specdefines that when the event is not being dispatched, these values should be
same as
pageXandpageY. However, we started computing the values withthe latest data since bug 1203404 for compatibility with the other browsers.
However, the test does not check the trusted event behavior. When the event
is a trusted event,
Event::DuplicatePrivateData()clearsEvent::mPresContext. Then, callingEvent::GetOffsetCoordswith specifyingmPresContextaborts to compute it [2]. Therefore, our mouse events return0foroffsetXandoffsetYafter propagation.Blink and WebKit caches
offsetXandoffsetYvalues when they are referredfirst time [3][4]. Therefore, their values depend on when they are
referred. I don't think we should follow their tricky behavior immediately.
However, at least, we should return same computed result until the layout and
scroll position are not changed. Therefore, this patch makes
MouseEventkeeps storing
mPresContexteven after callingUIEvent::DuplicatePrivateData()and use it when callingEvent::GetOffsetCoords.Finally, this adds a WPT under
uieventsto check current behavior in thesimplest case (i.e., neither scroll position nor layout is not changed after
starting the propagation).
Differential Revision: https://phabricator.services.mozilla.com/D232589
bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1931692
gecko-commit: 42de37e6c1b427a7a0b66aeaa2084dd4a1d8a408
gecko-reviewers: smaug