1907967 - `mouseover` event is erroneously fired after drag and drop of tab in tab browser

Status: VERIFIED FIXED

(Core :: DOM: Copy & Paste and Drag & Drop, defect)

Description

[Jeremy Swinarton]

Attachment: Original screencast demonstrating the bug, filed on bug1881782

This behaviour is the underlying cause of bug1881782 and is reproducible on Nightly 130.0a1 (2024-07-15) on MacOS.

To reproduce:

• Open a series of tabs
• Mouse over a tab and drag it to a new location in the tab bar
• Release the mouse button, and do not move the mouse after releasing it

The new tab that is in the position that the original tab was in before dragging will appear as though it is being hovered over.

This was originally reported as an issue with the new tab hover preview (THP) feature, but on investigation, this appears to be caused by an underlying DOM issue where a mouseover event is fired at the incorrect time and pixel location. Just after the drag is complete, the event is fired, but the pixel location of the event corresponds to where the mouse was before the drag started. This is passed down the stack and eventually received by the tab that is now in the position of the old tab, which receives the hover event.

Comment 1

[:Gijs (away/busy until Mar 10)]

(In reply to Jeremy Swinarton from comment #0)

this appears to be caused by an underlying DOM issue where a mouseover event is fired at the incorrect time and pixel location. Just after the drag is complete, the event is fired, but the pixel location of the event corresponds to where the mouse was before the drag started. This is passed down the stack and eventually received by the tab that is now in the position of the old tab, which receives the hover event.

Masayuki, this is what I was referring to in matrix the other day. Is this something we can fix on the platform side, or where we can provide more information so we can specifically ignore this synthetic mouseover event in the frontend JS code?

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I'm not sure. My first question is, why this is reproducible on macOS because the synthesized mouse move events which cause the mouse boundary events are enqueued and dispatched in completely cross platform code (PresShell and EventStateManager). Therefore, I have no idea why this is reproducible only on macOS.

The synthesized mouse move event is enqueued when:

• DOM mutation occurs (like the element under the cursor is removed
• a reflow ends
• a scroll occurs

Then, it's start to dispatch when the refresh driver notifies PresShell of a refresh. Then, the event will be dispatched on where the last mouse cursor is recorded in the PresShell. It's recorded when the PresShell gets received a mouse button event or a real mouse move and cleared when the cursor is moved out from the document.

Oh, okay, then, it could be caused by something different about events which PresShell receives during a drag session, but I'm not familiar with it. Edgar might know, but he is not available for a while...

Comment 3

[Jeremy Swinarton]

Attachment: tab-drag-bizarre-mouseover.png

Comment 4

[Jeremy Swinarton]

Attachment: window-maximize-bizarre-mouseover.png

Comment 5

[Jeremy Swinarton]

The plot thickens ... it turns out that bug1904792, which only happens on Windows, is also caused by a stray mouseover event that is fired in the wrong pixel location, but this time after the maximize button is clicked.

What's more, I originally thought that the tab-drag bug (bug1881782) was a MacOS only issue, since it is only visible on mac, but it appears that Windows is also affected, albeit in in a way that makes the end result invisible to the user. You can only verify it by observing mouseover events in the console. I've attached screenshots that help show what is happening.

When a tab is dragged (see tab-drag-bizarre-mouseover.png), the mouseover event appears directly after, and the clientX and clientY params appear to point to a position just over the third tab in the tab strip. This is especially bizarre because:

• in this example I dragged the tab from the first position in the strip, not the third
• somehow, on Windows, despite being in the wrong pixel location, the event is fired on the correct tab's DOM element (in this case the Twitter tab. you can kind of see this in my debug screenshot -- in the console I have the log breakpoint set to print this.label which is the label of the tab receiving the event). This is not the case on MacOS. On mac, the clientX and clientY parameters correspond to the exact location where the drag event started, and the DOM event is fired against the tab that is in that location.

When the window is maximized (see window-maximize-bizarre-mouseover.png), the mouseover event targets the fifth tab in the tab strip, but the pixel location actually points roughly to the top-right corner of the second tab.

One thing I did notice is that the clientX value appears to somehow be tied to the size of the browser window. In the maximization case it always seems to correspond to around 40-50% of the window's width.

EDIT: I did some more testing on macos to see if I could repro this issue in other ways (fullscreening and un-fullscreening, window resizing, creating and removing tabs with the keyboard) but have come up short. One thing I did notice is that if you drag a tab and then drop it on the original location, the mouseover event is not fired.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Thank you for the investigation. Sounds like that PresShell::RecordPointerLocation should update mMouseLocation when eDragOver and eDrop and reset it when eDragExit?

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Okay, my experimental patch works.

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 1907967 - Rewrite `PresShell::RecordPointerLocation` with `switch` statement r=smaug!,#dom-core

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 1907967 - Change printfs for logging synthesizing mouse moves to MOZ_LOG r=smaug!,#dom-core

I think that it should be available only in the debug build for the
performance.

Depends on D217078

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 1907967 - Make `PresShell::RecordPointerLocation` record mouse location and enqueue a synthetic mouse move if a drag event occurs r=smaug!,#dom-core

During a drag session, mouse events are not fired. Therefore, once the drag session
ends, mouse cursor may be anywhere different from the drag start position.
Therefore, PresShell should update the last mouse position when it receives drag
events and needs to synthesize a mouse move after the drag session ends to fire
mouse boundary events and updating the hover state.

Depends on D217079

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/da730ab8ea20
Rewrite `PresShell::RecordPointerLocation` with `switch` statement r=smaug
https://hg.mozilla.org/integration/autoland/rev/146366f2e096
Change printfs for logging synthesizing mouse moves to MOZ_LOG r=smaug
https://hg.mozilla.org/integration/autoland/rev/b3dc56f4f18a
Make `PresShell::RecordPointerLocation` record mouse location and enqueue a synthetic mouse move if a drag event occurs r=smaug

Comment 12

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/da730ab8ea20
https://hg.mozilla.org/mozilla-central/rev/146366f2e096
https://hg.mozilla.org/mozilla-central/rev/b3dc56f4f18a

Comment 13

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Surprisingly, this bug appeared at least since 1999!
https://searchfox.org/mozilla-central/diff/2c742db83b1ecf15fb7c3873a2b9def33eddf9ad/layout/base/nsPresShell.cpp#1293

Comment 15

[:Gijs (away/busy until Mar 10)]

I looked for dupes and found at least one; bug 1175136 may also be a dupe but I don't know for sure as I'm not familiar with layout. :-)

Comment 16

[:Gijs (away/busy until Mar 10)]

And maybe:

bug 315649
bug 666864
bug 1197630
bug 1818517

Comment 17

[Jeremy Swinarton]

Hi :masayuki, I was able to confirm that bug1881782 no longer happens, but bug1904792 is still reproducible. I can still see the stray mouseover event being fired in this case.

Comment 18

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Commented in bug 1904792. I think the wrong coordinates issue is a different bug from what i fixed in this bug.

Comment 20

[Daniel Bodea [:danibodea]]

I have reproduced this issue on MacOS 11 with Release v129.0.2 and verified the fix in Beta v130.0 (RC). The hover tooltip is correctly displayed after the fix. Thank you!