After a top-level navigation, the new PresShell has no per-PresShell mouse state until a real mouse event arrives. PresShell::SynthesizeMouseMove bails on that empty state, so a JS-driven cursor or :hover change (e.g. `body.style.cursor = 'none'` triggered by a keypress) does not take effect until the user moves the mouse. PointerEventHandler still holds the static last-mouse state from before the navigation. When the previous owning PresShell has been torn down, claim that state for the new PresShell. The existing path in ProcessSynthMouseMoveEvent then dispatches a synthetic eMouseMove at the cached position. Gate the claim with three checks. Skip if another live PresShell still owns the state (e.g. a popup). Skip unless the widget that originally recorded the state matches aRootPresShell's widget, since PresShell::IsRoot() means root of the in-process presContext tree and the previous owner could have been on a different top-level window in the same content process. And use a new sLastMousePointerId static for the recovered pointerId, since sLastPointerId tracks any pointer (including touch) and would mismatch the eMouseMove dispatched downstream. Differential Revision: https://phabricator.services.mozilla.com/D301688
23 lines
471 B
HTML
23 lines
471 B
HTML
<!doctype html>
|
|
<title>Test for bug 2038491: synth mouse move dispatches after top-level navigation</title>
|
|
<script src="/tests/SimpleTest/SimpleTest.js"></script>
|
|
|
|
<script>
|
|
SimpleTest.waitForExplicitFinish();
|
|
|
|
function reportResult(passed, msg) {
|
|
ok(passed, msg);
|
|
SimpleTest.finish();
|
|
}
|
|
|
|
function runTest() {
|
|
window.open(
|
|
"file_synthmousemove_after_navigation.html",
|
|
"_blank",
|
|
"width=400,height=400"
|
|
);
|
|
}
|
|
|
|
SimpleTest.waitForFocus(runTest);
|
|
</script>
|