1864654 - Intermittent wpt failure in inert-iframe-hittest.html | Hit-testing doesn't reach contents of an inert iframe

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Hsin-Yi Tsai (she/her) [:hsinyi]]

The sub-test "Hit-testing doesn't reach contents of an inert iframe" fails intermittently.
For example: https://wpt.fyi/results/inert/inert-iframe-hittest.html?run_id=6265390278115328

Comment 1

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi Masayuki, can you please investigate this? Thank you.

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(sickish, maybe slower respose)]

The hover state is set at dispatching mouseover.
https://searchfox.org/mozilla-central/rev/90dce6b0223b4dc17bb10f1125b44f70951585f9/dom/events/EventStateManager.cpp#4852,4891-4892

This is kicked by the refresh driver. So I think that this is caused by a timing issue.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(sickish, maybe slower respose)]

Oh, but we don't know intermittent failure of this (no bug, and the ini file only has timeout issue). I wonder, what environment is used in wpt.fyi. If my guess is right, it seems that it has really slow refresh-rate.

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(sickish, maybe slower respose)]

Attachment: Bug 1864654 - Make `PresShell` flush pending synthetic `mousemove` before dispatching `mousedown` or `mouseup` r=smaug!,#dom-core

inert-iframe-hittest.html expects that :hover state should be updated
immediately after a pointer down. The state is updated by
EventStateManager::NotifyMouseOver [1] when we received a real or synthetic
eMouseMove. Therefore, the hover state may have not set yet if no refresh
occurs between the pointer down and checking the result.

Additionally, some WPT for UI Events and Pointer Events expect that mouseover
or mouseout should be fired before mouseup/pointerup if a preceding
mousedown or pointerdown event listener removes the target. So, this
patch may fix intermittent failures of them if there are.

Unfortunately, flushing the pending mousemove does not solve this issue
because synthesized mousemove flushes some other states too. E.g.,
gotpointercapture and releasepointercapture. They should be fired handled
later if explicit capture changes the capturing content in tricky case [2].

Therefore, this patch adds a new internal event message, eMouseBoundary,
which is never dispatched into the DOM (i.e., handled only by
EventStateManager) and never cause pointer events, but calls
EventStateManager::GenerateMouseEnterExit() only with a mouse event.

1. https://searchfox.org/mozilla-central/rev/90dce6b0223b4dc17bb10f1125b44f70951585f9/dom/events/EventStateManager.cpp#4852,4891-4892
2. https://searchfox.org/mozilla-central/rev/766a338d53cd29e9851107f9e6a62d333c7d2c51/layout/base/tests/bug977003_inner_6.html#37,40,73,88

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(sickish, maybe slower respose)]

Edgar, could you review the PointerEventHandler part? Thank you!

Comment 6

[Edgar Chen [:edgar]]

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #5)

Edgar, could you review the PointerEventHandler part? Thank you!

Done. :)

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5e411c1e0424
Make `PresShell` flush pending synthetic `mousemove` before dispatching `mousedown` or `mouseup` r=smaug,dom-core,extension-reviewers,edgar,robwu

Comment 8

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/44163 for changes under testing/web-platform/tests

Comment 9

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/5e411c1e0424

Comment 10

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot