Reliable reproduction, but minor issue:

• Hover a Bookmarks Bar bookmark (not folder), or HTML element with tooltip.
• Alt+tab to switch to a window. It should cover Firefox.
• The tooltip doesn't go away, no matter how long you wait, until mouse goes on the tooltip.

Unreproducible, more severe issue:

• I get a tooltip from an HTML element (or bookmark?).
• It shows up on other apps. Mousing over tooltip does not make it go away.
• The only solution is to switch to the tab which created the tooltip, and mouse over the HTML element causing the tooltip to appear.
• Sometimes that doesn't work, and I need to restart Firefox to make it go away.

Kubuntu 18.04. Most apps use Qt, but Firefox uses GTK3 for tooltips.

Hi Jimbo,

I was unable to reproduce this issue on Ubuntu 18.04.02 LTS with Firefox Release 68.0.1 64 bits. The tooltip remained when I changed back to firefox but disappeared two seconds later. But maybe you can provide me with a bit more info.

Does this issue occur with a fresh profile? you can find the steps here: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager

Can you please download Firefox Nightly from here: https://nightly.mozilla.org/ and retest the problem and see if the issue still occurs there as well?

If after doing this you can still reproduce the bug, could you send me a screenshot or a video of the bug? That always helps a lot.

Thanks in advance, Flor.

Let me reword my bug report:

Hover a Bookmarks Bar bookmark (not folder), or HTML element with tooltip. Then alt+tab to switch to a window which covers Firefox. The tooltip remains while the cursor is on the non-Firefox window or any other window, and disappears if the cursor touches Firefox or the tooltip.

I confirmed the issue on Nightly firefox-70.0a1.en-US.linux-x86_64.tar.bz2 with KDE KWin. I noticed that Firefox uses GTK3, which maybe does not interact well with KWin and Qt. Maybe Firefox is mostly tested in Gnome, and not enough in KDE.

Sidenote: Even if I don't alt+tab, I noticed that Firefox Linux tooltips last indefinitely if I hover a tab or bookmark. The tooltip only disappears when I move my mouse cursor away from its initial position. (However, native win32 tooltips disappear on a timer.)

Hi Jimbo,

Thanks for the details. I was able to reproduce the bug on nightly 70.0a1 (2019-08-05) (64-bit) on Linux 4.18 x86-64. I've chosen a component. If you consider that there's another component that's more proper for this case you may change it.

Regardless, I think it's related to this bug: 440652.

Best regards, Flor.

Also affected! This is interfereing with my workflow a lot. Another repro:

• Have another non-Firefox window overlap the browser window
• Move mouse to a bookmark in bookmarks sidebar
• Move mouse to the other window before the tooltip appears
• Tooltip will appear regardless and stick around until Firefox window or tooltip (which counts as part of the Firefox window) is hovered over again

So even if the mouse just passes a Firefox window it has a tendency to leave tooltips around.

Also confirming. I can reproduce using any of the methods above.

I'd like to add that the tooltip never times out for me, so I cannot make the persistent tooltip disappear unless I tab back into the application and move my mouse.

One can get rid of tooltips entirely with thise userChrome.css rule:

#remoteBrowserTooltip { display: none !important; }

This is of course also undesirable, but it beats dealing with tooltips that just won't disappear on their own.

Confirming this is still an active bug on a stock, fully updated Ubuntu 20.04 install.

I stick to using Chromium for my daily workflows as the tooltip irks me to no end. I get it every time I pull up the Gnome hot corner (configured to be top-left); the name of my left-most tab renders in a tooltip and won't go away until I tab back to Firefox, move my mouse around, then tab back to my active application.

Just for completeness sake: This bug also occurs in other GTK applications, like Quod Libet. It is probably not specific to Firefox.

(sorry, to be clearer: not only Firefox's tooltips can remain on screen indefinitely until touched with the mouse. It also happens with tooltips generated by other GTK apps.)

can't confirm. For me it's only Firefox tooltips.

For me the tooltip disappears too quickly. Using Firefox 88.0 on Elementary OS Linux with latest updates and kernel 5.4.0-72-generic.

Can confirm.

When I quickly switch the workspace with keyboard in KDE, the tooltip is not disappearing.

Tested on kwin_x11 5.22.4 with firefox 90.0.2

I can confirm this bug, super annoying.

Running Mozilla Firefox 100.0 with wayland on Arch Linux 5.17.5-arch1-1.

my about:support can be seen here: https://rentry.co/guwmq

I also have this bug. It happens only on Wayland, and it affects multiple GTK applications.

Mozilla Firefox 100.0, Manjaro 5.16.20-2

I haven't been able to find the bug in any other bug tracker, so posting this here. But it doesn't seem to be a FF bug.

Maybe there are two separate issues? I only get stuck tooltips in Firefox and Thunderbird on X11. Others get stuck tooltips with multiple GTK apps on Wayland.

(In reply to haarp from comment #16)

Maybe there are two separate issues? I only get stuck tooltips in Firefox and Thunderbird on X11. Others get stuck tooltips with multiple GTK apps on Wayland.

If it's a general issue, it definitely also occurs on X11 (here), in this case Quod Libet's tooltips will remain stuck, even after switching workspaces in GNOME.

I find a solution for my system. In about:config, set

gfx.webrender.compositor.force-enabled = false

This is the default value.

This is still an issue in Firefox 107 + X11.

Extremely annoying. Especially if you work with multiple workspaces, browser profiles and browser windows. You have to figure out which browser (or Thunderbird) that damn stuck tooltip originated from, so you can hover the cursor over the corresponding window to make it disappear.

(In reply to pavelpotocek from comment #18)

gfx.webrender.compositor.force-enabled = false

I have this option set to false, and am still getting stuck tooltips.

I can confirm this is still an issue for me on Firefox 107.0.1 and Thunderbird, on Fedora 37 running X11. I have also set the gfx.webrender.compositor.force-enabled = false flag to no avail as @haarp describes.

It is definitely pretty annoying especially when working with multiple workspaces.

This annoying bug also started to appear on my 107.0.1. The tooltip remains displayed on top of any other applications for as long as I don't return to the Firefox window. Incredibly annoying, because it is happening several times a day and hovering over important sections of other applications, making them unusable. How is such a cross-application render leak even possible?

(In reply to combic@o2.pl from comment #21)

This annoying bug also started to appear on my 107.0.1. The tooltip remains displayed on top of any other applications for as long as I don't return to the Firefox window. Incredibly annoying, because it is happening several times a day and hovering over important sections of other applications, making them unusable. How is such a cross-application render leak even possible?

The tooltips are probably frameless windows, i.e. rendered by the window manager.

I have this problem too.

Firefox 108.0 (64-bit)
Ubuntu 22.04.1 LTS

Is this fixed in 109 / nightly? bug 1798131 fixed it for me on GNOME+X11, though IIRC some other users could also reproduce something similar (but that seemed like an X server bug, because the leave-notify events weren't sent).

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

Is this fixed in 109 / nightly? bug 1798131 fixed it for me on GNOME+X11, though IIRC some other users could also reproduce something similar (but that seemed like an X server bug, because the leave-notify events weren't sent).

Thanks for that bug report, it seems to indeed be the same issue. I'll have to wait for v109, but in the meantime I confirm that starting Firefox/Thunderbird with MOZ_GTK_TITLEBAR_DECORATION=system works around the issue! Yay!

Firefox 107.0.1. Fedora Linux 36. Problem is actual :(

I would have thought this is a race condition, related to the timing of mouse movement; it happens to me on Xorg but only with a certain speed when it comes to putting the mouse cursor off the Firefox widget (ex: tab), but it happens much more easily if the browser is in the background rather than the foreground.

As such, out of curiosity, although some are reporting the issue as fixed through bug #1798131, is this really different from the venerable bug #148624 ? It sounds pretty similar, and that one has a ton of duplicates...

Can confirm the issue on Firefox 108.0.2 (64-bit) and Firefox-Developer-Edition 109.0b9 (64-bit), on ArchLinux (Rolling - up to date), with Gnome 43 (Wayland).

I have been able to partially mitigate the issue by disabling toolbar tooltips by setting browser.chrome.toolbar_tips to false under about:config

Before finding the above workaround, it was extremely annoying, to the point of making me heavily consider using a different browser entirely.

It is so annoying during my workflow, happening tens if not hundreds of times a day when switching windows and I have to stop using Firefox for now.
It may be helpful for you to fix this problem by looking at the Chromium way of solving it. In Chromium when you are going to perform any action with your keyboard (e.g. pressing the Alt or Shift or Ctrl keys - in order to switch windows with Alt+Tab) any displayed tooltips are immediately disappearing. IMO the same will work for Firefox. When any key is pressed - immediately reset any tooltips.

That might not work because the mouse focus and the keyboard focus might not be in the same window.

This should've been fixed on 109 for users with default settings, but I can repro if I turn on MOZ_USE_XINPUT2.

This approach works and is rather simple, but it doesn't work in the case the
tooltip is from content and isn't in the focused window.

This ensures that tooltips don't stick around if the window manager
doesn't send correct leave-notify events.

Depends on D166943

https://hg.mozilla.org/mozilla-central/rev/4ff8b13cc027
https://hg.mozilla.org/mozilla-central/rev/77961ca398c6