1892527 - "Reply" popups in Facebook browser chat don't disappear on scroll out or timeout and stay permanent until page refresh

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect, P2)

Description

[dicska]

Attachment: 00_firefox_pls_floatingpopup.mp4

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:125.0) Gecko/20100101 Firefox/125.0

Steps to reproduce:

Brought up an arbitrary chat on facebook.com (desktop browser) and hovered the "reply" back arrow on any chat bubble in any chat, then waited for it to disappear after a few seconds; then moved the mouse and waited a bit; then tried to get rid of it by scrolling it out of the chat tab.

Actual results:

The popup/popout "Reply" label (and one of the "More" labels) stayed on screen, annoyingly covering the chat.

Expected results:

The "Reply" (and/or "More") popup/popout label should have disappeared after a certain amount of time and/or after moving the mouse cursor away.

Comment 1

[dicska]

Additional information:
Interestingly, I managed to get rid of some of the "stuck" labels by moving the cursor through them (at this point they still didn't disappear) AND scrolling them away with the chat's scrollbar; some of them couldn't be removed the same way, however. In the attached video, the middle "Reply" and the bottom "More" labels were still stubborn and stayed on after this process. Then I hovered the scrollbar and got rid of the "More" label but the center "Reply" still stands strong. I even tried clicking stuff - nothing.

Comment 2

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

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Win32' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Ray Kraesig [:rkraesig]]

The 'Core::Widget: Win32' triage owner thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please correct in case you think the human is wrong.

Comment 4

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

I can reproduce it fair easily, though not always. I seem to not see this problem on Chrome.

Hi Dennis, can you/your team help us to look into the site code a bit? Thank you.

Comment 5

[Dennis Schubert [:denschub]]

I had a look, but couldn't immediately figure it out, so this needs a bit more time. I'll move this into the WebCompat component for now so we can do diagnosis on that.

Comment 6

[James Graham [:jgraham]]

My guess here would have been something DOM or APZ related, on the basis that the nodes aren't being removed in response to the events, but given that Hsin-Yi already looked a bit, I'll set the diagnosis-team to WebCompat for now. But we could move this out again if the queues are unbalanced.

Comment 7

[Daniel Holbert [:dholbert]]

Reporter (or others): are you still seeing issues along the lines of what the screencast showed in comment 0 here? In particular: do you end up with multiple of these tooltips at the same time, and do they stick around even after you move your mouse cursor (as in comment 0's screencast)?

So far in my attempts to reproduce (in Firefox Nightly on Linux and macOS), I can only manage to get one of these tooltips to show up at a time, and that one tooltip disappears as soon as I move my cursor.

I can make the tooltip stays there (persistently) if I two-finger-scroll on my touchpad, but it disappears as soon as I move the cursor on screen the slightest bit. In Chrome, the tooltip doesn't stick around; it disappears as soon as my two-finger-scroll action causes the associated hovered-element to lose focus.

(Also: for me, the reply-button's tooltip is harder to make this bug reproduce with. That particular tooltip disappears when my two-finger-scroll action causes other content to move under my cursor. Other larger-tooltips from other elements -- like e.g. the datestamp-tooltip that shows up when I hover an actual chat message -- seem to stick around more persistently. But as noted above, I can only get one of those at a time to show up.)

Comment 8

[Daniel Holbert [:dholbert]]

Let's put this in the APZ diagnosis bucket for now, given that the interop issue that I'm able-to-repro here seems related to whether-or-not we dispatch certain mouse/hover events when scrolling (as opposed to moving the mouse cursor).

Comment 9

[dicska]

(In reply to Daniel Holbert [:dholbert] from comment #7)

Reporter (or others): are you still seeing issues along the lines of what the screencast showed in comment 0 here? In particular: do you end up with multiple of these tooltips at the same time, and do they stick around even after you move your mouse cursor (as in comment 0's screencast)?

So far in my attempts to reproduce (in Firefox Nightly on Linux and macOS), I can only manage to get one of these tooltips to show up at a time, and that one tooltip disappears as soon as I move my cursor.

I can make the tooltip stays there (persistently) if I two-finger-scroll on my touchpad, but it disappears as soon as I move the cursor on screen the slightest bit. In Chrome, the tooltip doesn't stick around; it disappears as soon as my two-finger-scroll action causes the associated hovered-element to lose focus.

(Also: for me, the reply-button's tooltip is harder to make this bug reproduce with. That particular tooltip disappears when my two-finger-scroll action causes other content to move under my cursor. Other larger-tooltips from other elements -- like e.g. the datestamp-tooltip that shows up when I hover an actual chat message -- seem to stick around more persistently. But as noted above, I can only get one of those at a time to show up.)

Thanks for the message because I honestly almost forgot about the whole thing: I don't even remember when, but these problems definitely ceased to happen. I tried to reproduce them just now, and it looks like it has been solved - at least in my case. I can't speak for other OSes and distros.
Thank you everyone for all your time and effort; I truly appreciate everyone's work here. Please let me know if I should close it or something.

Comment 10

[Daniel Holbert [:dholbert]]

Thanks! That's great to hear.

I'll close this out tomorrow and spin off a follow-up bug for the thing that I'm seeing, but it's definitely lower severity than what was in your original screencast here.

Comment 11

[Daniel Holbert [:dholbert]]

I filed bug 1931600 on the still-reproducible thing I described in comment 7, and let's close this bug here as WORKSFORME given comment 9.