1931600 - Facebook Messenger chat-message-tooltips don't disappear when scrolling, until you move mouse cursor

Status: NEW

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[Daniel Holbert [:dholbert]]

Attachment: screencast of bug (showing Firefox for first 15 seconds vs. Chrome for last 15 seconds)

(Spinning off of bug 1892527 for a less-severe piece of that bug that's still reproducible.)

STR:

1. Go to https://www.facebook.com/ and sign in.
2. Open a messenger chat conversation (e.g. by tapping messenger icon at top right, and choosing some conversation)
3. Hover a message in your chat so that a timestamp tooltip/popup appears.
4. Now, being very careful not to move your mouse-cursor position, use two-finger-scrolling (or a mousewheel) to scroll upwards in the chat message history, far enough so that you're not hovering the message anymore (or even hovering a different message)

ACTUAL RESULTS:

• The timestamp tooltip/popup stays there, even though I'm no longer hovering the content that it's associated with.
• If I end up hovering a different message (or some other tooltip-having-content), no tooltip shows up for that element.
• When I actually move my cursor, only then do things get un-stuck and the old tooltip disappears and a new one appears for whatever I might be hovering (as-expected).

EXPECTED RESULTS:
The old tooltip/popup should disappear as soon as my scrolling takes the associated element out from under my cursor. (And if I end up hovering another element, its tooltip should appear, without me needing to explicitly move the mouse.)

Firefox Nightly 134.0a1 (2024-11-14) gives ACTUAL RESULTS.
Chrome 130 gives EXPECTED RESULTS.

Comment 1

[Daniel Holbert [:dholbert]]

Note, the tooltips here aren't "real" tooltips (they're not the tooltips generated by the title attribute). They're actual DOM elements that Facebook dynamically generates and adds/removes in the page's DOM, based on Facebook's own logic and event listeners.

I tried using devtools to do "break on: subtree modification" on the ancestor to catch when it's inserted/removed, hoping to see what mouse event they were watching for; but the backtrace looked like it was hundreds of layers deep (and it's all minified JS with meaningless function/variable names), so I couldn't make much sense of it.

Comment 2

[Daniel Holbert [:dholbert]]

Triage note: this is probably S3-level since it's pretty subtle and doesn't substantially break the site (and if you move your cursor at all, you'd never notice this). I'll leave triage unset, though, so that this gets seen in the APZ triage meeting.

(Also not sure whether this belongs in APZ vs. Layout:Scrolling&Overflow; I'll leave that to the APZ folks to reclassify if appropriate.)

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:botond, could you have a look please?

For more information, please visit BugBot documentation.

Comment 4

[Dan Robertson (:dlrobertson)]

Agreed. I'd definitely say this is an S3/P3, and as for the component, I'll leave this in APZ instead of Layout:Scrolling & Overflow. My initial suspicion is that this is an issue in the ActiveElementManager. I don't have a facebook account, but does this still occur with dom.event.wheel-event-groups.enabled set to false? Again, just a suspicion, but I wonder if this is partially caused by wheel event groups.

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Dan Robertson (:dlrobertson) from comment #4)

I don't have a facebook account, but does this still occur with dom.event.wheel-event-groups.enabled set to false?

I can still reproducible with that pref set to false -- I still see the behavior shown in the screencast.

(I just tested on current Nightly 136.0a1 on Linux. I restarted Firefox after the pref flip for good measure, too.)

Comment 6

[Botond Ballo [:botond]]

(In reply to Dan Robertson (:dlrobertson) from comment #4)

My initial suspicion is that this is an issue in the ActiveElementManager

ActiveElementManager is pretty specific to touch input, whereas this issue occurs with mouse input.

This seems more like a DOM issue to me, e.g. some sort of subtle difference between Firefox and Chrome with exactly when and where mouseover/mouseout/mouseenter/mouseleave events are fired.

Comment 7

[Botond Ballo [:botond]]

I'm going to move this bug to a DOM component on the suspicion that it's related to mouseover/mouseout/mouseenter/mouseleave events (as mentioned in the previous comment). Please feel free to move it back if I'm mistaken about this.

Comment 8

[Henri Sivonen (:hsivonen) (not reading bugmail until 2026-07-27)]

smaug, do you have insight into the specifics of the events mentioned in comment 7.