Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Make
PresShell
flush pending synthetic mousemove
before dispatchi…
…ng `mousedown` or `mouseup `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. Therefore, we should flush pending synthetic `mousemove` event for keeping the event order as same as they happen. However, simply flushing it causes unexpected pointer capture state change because `PointerEventHandler::ProcessPointerCaptureForMouse` handles synthetic `mousemove` but it should not cause pointer boundary events at the moment (the pointer boundary events should be fired when the pointer is actually moved, note that this is different rule from the rules of mouse boundary events). Therefore, this patch changes `PointerEventHandler::ShouldGeneratePointerEventFromMouse`. However, this blocks `lostpointercatpure` event when the capturing content has already been removed from the DOM tree. The path is, `EventHandler::HandleEventWithPointerCapturingContentWithoutItsFrame` stops dispatching `pointerup` nor `pointercancel` in this case, but `EventStateManager::PostHandleEvent` is the only handler of implicit pointer capture release. Therefore, we need to make it dispatch lostpointercatpure` event if the canceling event caused `ePointerUp` or `ePointerCancel`. Finally, this patch fixes a bug of `browser_ext_browserAction_popup_preload.js`. It tests the pre-loading which starts when `mouseover` before `mousedown` on a widget. However, it does not correctly emulate the user input. * Synthesizing only `mouseover` does not update the internal pointer info and does not cause dispatching related events. * Synthesizing `mousedown` without `mousemove` cause `mouseover` before `mouseup` because at dispatching `mousedown`, `PresShell` stores the cursor [2] and the mouse boundary events will be dispatched before `mouseup`. `ext-browserAction.js` assumes the events are fired as this order, `mouseover` -> `mousedown` -> `mouseup`, but this would not work if the preceding `mousemove` of `mousedown` is not correctly fired. I'm not sure whether `mousemove` is always fired before `mousedown` on any environments, but it should be rare and it affects only this kind of tricky code. For now, fixing this in the test side must be enough. 1. https://searchfox.org/mozilla-central/rev/9a5bf21ea2dd04946734658f67f83f62ca76b0fa/dom/events/EventStateManager.cpp#4874,4913-4914 2. https://searchfox.org/mozilla-central/rev/9a5bf21ea2dd04946734658f67f83f62ca76b0fa/layout/base/PresShell.cpp#6756 Differential Revision: https://phabricator.services.mozilla.com/D193870 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1864654 gecko-commit: 5e411c1e0424f542714c947b1c82020e13e211a9 gecko-reviewers: smaug, dom-core, extension-reviewers, edgar, robwu
- Loading branch information