1824887 - [X11] Stuck tooltips do not disappear on Linux when another window is overlapping parts of the Firefox window, or when using GNOME's hot corner

Status: RESOLVED DUPLICATE of bug 1843205

(Core :: Widget: Gtk, defect, P3)

Description

[Jeff Fortin]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/111.0

Steps to reproduce:

Note: this is a continuation of bug #1569439. It fixes half of the issue, but another part remains. Two ways to trigger it:

Method A:

1. While running GNOME Shell with the dash-to-panel extension, positioned at the bottom (which eliminates the top panel), move the mouse to the top-left screen hot corner right after hovering some of the (pinned) tabs on Firefox's top-left corner
2. The hot corner activates GNOME Shell's overview mode; switch to another application.
3. Result: tab tooltip stuck until you focus back to Firefox's window to get rid of it

Method B:

1. Have another window overlapping on top of parts of Firefox's window, but not obscuring the tabs strip.
2. Move the mouse somewhere on top (hovering) of Firefox's tab strip; tooltips appear
3. Quickly move the mouse away to the other app's currently overlaid window

Actual results:

On Xorg/X11, the tooltip stays stuck.

Expected results:

Firefox should:

• dismiss tooltips whenever the window loses focus (helps with the hotcorner / fullscreen problem)
• detect that the mouse movements are happening somewhere other than directly over it (helps with the "another partially obscuring window is overlaid on top" problem)

Comment 1

[Jeff Fortin]

Attachment: Video demonstrating the problem (with method B)

Comment 2

[Jeff Fortin]

Another potential way (let's call it "method C") to trigger the bug, but it does not always occur reliably:

1. Open a github ticket page (such as this one, for example)
2. Hover your mouse cursor over the "Leave a comment" description field at the bottom (in the "Write" tab).
3. Alt+Tab to another window within the same desktop workspace, so that the other window blocks Firefox from view.

Result: the "Please fill out this field." tooltip sometimes remains shown through the overlaid app. I'm not sure under what conditions, because it does not happen everytime, it might have something to do with how fast you do the alt+tab window switching.

Comment 3

[biggestsonicfan]

My main issue is I usually alt+tab before the tooltips are drawn. I unknowingly have my cursor over an element which will draw a tooltip, alt+tab to another window, even a full-screen window, and the tooltip will not go away until I move my cursor over the origin (Firefox) window. Was hoping this was fixed in 1569439, but my use-case that's been happening for several years persists.

Comment 4

[Jeff Fortin]

Another way to very easily trigger the issue in Firefox: simply installing the Tab Center Reborn extension, hit Shift+F1 to turn on the tabs sidebar, focus some other window than Firefox, and move the mouse above the area where the tabs are shown in Firefox's sidebar; guaranteed sticky tooltips there, more so than the regular tab strip even. I'm not sure if it uses the same code path within Firefox, but probably worth testing too as part of the fix...

Comment 5

[Jackson Sul]

Is this the same issue as bug 1809029? I have these issues in KDE, but only when XINPUT2 is set to be used (MOZ_USE_XINPUT2=1). I think some, but not all, distros enable that by default.

Comment 6

[Todd M. Lewis]

Still seeing this with Firefox 115.0 on Fedora 38. Super annoying.

My common reproducer scenario: I have my UI pref "Focus follows mouse" set, so simply moving the mouse can change which window has focus without changing any windows' relative depth. If a Firefox tooltip is showing when I move my mouse to another window — which happens often with overlapping windows — the non-Firefox window gains focus while the Firefox window loses focus. However, the element within the Firefox window associated with the tooltip retains content focus even though the containing window no longer has window focus.

I can see why elements should retain content focus even when their containing window loses focus. For example, if the user is entering text in a text box, the expectation would be that upon returning to that window, the text box would still be active with the cursor in the same spot.

However, for the purposes of tool tips, when the containing window loses focus, the equivalent of the user hitting "Esc" should happen. That is, any active tool tip should be closed when the containing window loses focus, while any active/selected element(s) in that window's contents should remain active/selected/focused. (I'm probably a little sloppy wrt these technically precise terms like "active", "selected", and maybe even "focus", but I hope you get the idea.)

Comment 7

[Emilio Cobos Álvarez (:emilio)]

(In reply to Todd M. Lewis from comment #6)

However, for the purposes of tool tips, when the containing window loses focus, the equivalent of the user hitting "Esc" should happen. That is, any active tool tip should be closed when the containing window loses focus, while any active/selected element(s) in that window's contents should remain active/selected/focused. (I'm probably a little sloppy wrt these technically precise terms like "active", "selected", and maybe even "focus", but I hope you get the idea.)

That's what the code does here. If that doesn't happen then that means that your WM / X Server is not sending the right focus events, or GTK is eating them, or something along those lines.

I haven't been able to reproduce this. Btw, I wonder if this and the other bug have been fixed by bug 1843205. Can someone that reproduces this test https://nightly.mozilla.org?

Comment 8

[Todd M. Lewis]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #7)

(In reply to Todd M. Lewis from comment #6)

However, for the purposes of tool tips, when the containing window loses focus, the equivalent of the user hitting "Esc" should happen. That is, any active tool tip should be closed when the containing window loses focus, while any active/selected element(s) in that window's contents should remain active/selected/focused. (I'm probably a little sloppy wrt these technically precise terms like "active", "selected", and maybe even "focus", but I hope you get the idea.)

That's what the code does here. If that doesn't happen then that means that your WM / X Server is not sending the right focus events, or GTK is eating them, or something along those lines.

I haven't been able to reproduce this. Btw, I wonder if this and the other bug have been fixed by bug 1843205. Can someone that reproduces this test https://nightly.mozilla.org?

Just now tested on nightly 117.0a1 (2023-07-18), and indeed it appears to be fixed!
I'm extremely pleased. Can't wait for this to work its way thorough the Fedora updates.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Ok let's close as a dupe, and reopen if it still happens for someone else. Thanks!