148624 - (tooltip-ghost) Tooltips persist in foreground when Firefox is in background

Status: VERIFIED FIXED

(Core :: XUL, defect)

Description

[Adam Price]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.0+)
Gecko/20020602
BuildID:    2002060203

If I mouseover a toolbar link, and wait for a second, a little yellow box with
the description of the link appears.  If I now use command-tab to move Mozilla
to the background, the little yellow box stays there, in the foreground.  The
only way to get rid of it is to put mozilla in the foreground again, and move
the mouse off the toolbar.

Reproducible: Always
Steps to Reproduce:
1.Mouseover a toolbar icon
2.Wait for tooltip
3.Command-tab

Actual Results:  The tooltip wouldn't go away

Expected Results:  The tooltip should have gone away when mozilla was backgrounded

This is related to the following bugs.  I am resubmitting because the other
reporters did not give good step by step reproduction methods, or the problem is
slightly different:

<http://bugzilla.mozilla.org/show_bug.cgi?id=131131>Tooltips show up over other
windows 

*
<http://bugzilla.mozilla.org/show_bug.cgi?id=142656>
Tooltips occasionally don't disappear

*
<http://bugzilla.mozilla.org/show_bug.cgi?id=61157> 
Tooltips appear even when mouse isn't over node

*
<http://bugzilla.mozilla.org/show_bug.cgi?id=116447> 
tooltip persists after autocomplete dropdown appears

*
<http://bugzilla.mozilla.org/show_bug.cgi?id=45497> Tooltip should disappear
when parent item disappears

Comment 1

[Greg K.]

Confirmed using FizzillaCFM/2002052305 (RC3).

Guessing XP Toolkit/Widgets.

Comment 2

[Jerry Baker]

See this on WinXP as well. --> OS/All & Platform All

Comment 3

[Jerry Baker]

Attachment: Tooltip over another app, Mozilla minimized

This doesn't requires an ALT-TAB. I can reproduce this by dragging a link from
the URL bar onto my desktop, by dragging a link up to the "X" in the upper
right corner and letting go and clicking the X. Lots of ways.

Comment 4

[John A.]

I'm seeing this problem in 1.6 on Win98.

Comment 5

[riscky]

*** Bug 242912 has been marked as a duplicate of this bug. ***

Comment 6

[Malcolm Smith]

Also happens in Firefox/0.8, Linux GTK2, although in this case the offending
tooltips can be killed by moving the mouse pointer over them. Still very
annoying though.

Comment 7

[Malcolm Smith]

Should be marked as a duplicate of Bug 142656.

Comment 8

[Uri Bernstein]

*** Bug 262649 has been marked as a duplicate of this bug. ***

Comment 9

[Uri Bernstein]

*** Bug 295742 has been marked as a duplicate of this bug. ***

Comment 10

[Jerry Baker]

Just a ping and a note that this is still occuring in the latest builds of
Firefox and Thunderbird.

Comment 11

[Jerry Baker]

Not only do tooltips persist in the foreground, but they can pop up even when
Firefox is in the background and the mouse passes over a point that would
generate a tooltip if Firefox was in the foreground.

Comment 12

[Jerry Baker]

This behaves as though Firefox/Thunderbird are unaware that the mouse pointer
has exited their window and is not in another window. Somehow they continue to
receive coordinates even though there is another window over them. One nasty
example fo this bug is to load a PDF file and then drag the mouse from the URL
bar, across the personal toolbar, and into the PDF content. A tooltip from the
personal toolbar will pop up over the PDF and will never go away until you
mouseover it.

Comment 13

[Jerry Baker]

Make that, "and is now in another window"

Comment 14

[Mike Beltzner [:beltzner, not reading bugmail]]

*** Bug 335527 has been marked as a duplicate of this bug. ***

Comment 15

[Mike Beltzner [:beltzner, not reading bugmail]]

*** Bug 323120 has been marked as a duplicate of this bug. ***

Comment 16

[Joey Minta]

*** Bug 342427 has been marked as a duplicate of this bug. ***

Comment 19

[Aaron Digulla]

How about disabling tooltips when the Firefox window is inactive?

Comment 20

[Dan S]

This is really annoying. I'm on OSX, using Sunbird, and these tooltips keep appearing which I can't get rid of despite having only flicked quickly to Sunbird to check my calendar. It makes me quit sunbird, that's the easiest way to get rid of the things!
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.8pre) Gecko/20071002 Sunbird/0.7

Comment 21

[Nik]

I don't have sunbird, BUT I agree with you Dan!
ON a Mac and it still happens in Firefox 2.0.0.14 

I've been I've been bitchin about this bug since 2004 (see bug: 236870) -- Which is obviously a dupe of this bug...  But it never seems to go away! -- 

Bug still appears on Mac in:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.14)
Gecko/20080404 Firefox/2.0.0.14

But it's a bit harder to replicate.

To replicate in 2.0.0.14:
1: Mouse over something that generates a tip.
2: Hit "Command" (Apple) -- TIP DISAPPEARS (yay!)
3: (still holding Command) Slightly move mouse -- TIP REAPPEARS (Oh-Oh)
4: Hit "TAB" to complete the switch to another app -- TIP REMAINS (#*$%!)

Tip remains until you switch back to Firefox... This sounds minor.. But it's
very frequent for users of track pads that do a lot of switching! -- Others in
our office have tihs problem!

BUT there may be hope on the horizon.. I've had trouble replicating this in
Firefox 3 RC 2, the tip stays when you switch, but as soon as you move the
mouse, it disappears (keyboard events don't clear the tip unfortunately).

Cheers,
Nik.

Comment 22

[Dan S]

Still happening, exactly the same, on Sunbird 0.8 :(((

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.13pre) Gecko/20080331 Sunbird/0.8

Comment 23

[Emerson Prado]

I saw this with Lightning 0.9 build 2008091719 in Thunderbird 2.0.0.17 (20080914), all pt-BR, over Win2k SP4 en-US.
I opened a task for edition and moved the mouse to the reminder window. In its way, the mouse crossed the tasks pane and a tooltip came (too quick, IMHO). Even after clicking in the reminder window (to get focus), the tip stayed on top of it. I had to play with the mouse a bit to get rid of the tip (can't remember if I just moved it around or clicked somewhere else).

Comment 24

[Emerson Prado]

Attachment: Task tooltip over reminder window, which was focused

Comment 25

[Seth Spitzer]

I'm not seeing this in fx 3.6.11 (and I didn't see it with 3.6.8, fwiw) on Mac OS X.

Specifically, the STR in commment #21.

Neil, could you have fixed this along the way somewhere?

Comment 26

[Seth Spitzer]

fwiw, on mac, fx 3.5, 3.0.19 and even 3.0 do not have this bug, but fx 2.0.0.20 does.

I wonder if this was fixed by neil's work for #279703 (or one of the dependent bugs)?

Comment 27

[Richard Newman [:rnewman]]

Attachment: Still happens in Fx4 nightly.

I see this in 3.6.12 (on 10.5.xx and 10.6.5) and a 2010-12-03 nightly on 10.6.5.

It's been driving me nuts for years. Most definitely not fixed.

Here's an observation which might explain "worksforme" responses.

If Fx is the frontmost app, the Cmd key that I use to initiate Cmd-Tab will cause the tooltip to disappear.

If Fx is *not* the frontmost app, it still responds to hovers and throws up a tooltip... but the frontmost app takes keyboard input, so Fx isn't aware of any app or window changes. It's thus possible to Cmd-Tab to an app that should cover the tooltip, but the tooltip stays on top.

Easy enough to repro: give focus to the Finder, hover over a tab or link in Firefox without shifting focus, then Cmd-Tab to an app that would be over the link when taking focus (such as a maximized iTunes window).

Tiny screenshot attached.

Comment 28

[Seth Spitzer]

Richard:  killing this bug would be great.

What about not showing tooltips (when that timer fires) if the window doesn't have focus?

in nsXULTooltipListener::ShowTooltip() we call LaunchTooltip()

In ShowTooltip() we already get the document for the tooltip node

From that, can we get the nsPIDOMWindow and then ask the focus manager if we are the focusedWindow?

http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/base/nsIFocusManager.idl#71

Similar to this code:

http://mxr.mozilla.org/mozilla-central/source/editor/libeditor/html/nsHTMLEditor.cpp#5963

Comment 29

[Richard Newman [:rnewman]]

(In reply to comment #28)
> Richard:  killing this bug would be great.
> 
> What about not showing tooltips (when that timer fires) if the window doesn't
> have focus?

That seems like a reasonable approach. Safari (to take a sample of the playing field) doesn't show tooltips if it's not the foreground app.

If no XULian takes a stab at this, I might be tempted — at least, after my urgent Sync commitments are done… it's a real annoyance to me.

Comment 30

[Seth Spitzer]

bookmarks on the bookmarks toolbar in 3.6.12 will not change style or give me a tooltip on hover if firefox is not active.  (Richard, can you double check 3.6.12?)

But I can confirm that firefox 4.0b7 does do it.

another sample from the playing field:  Google Chrome (on Mac) doesn't seem to show tooltips it's not the foreground app, either.

From my tests:

1)  firefox 4.0b7 has a different regression (what Richard describes in comment #27)
2)  neither fx 3.6.12 nor 4.0b7 have the bug described comment #21, which is why I thought this bug is now fixed/worksforme.  Unfortunately, I don't know what fixed it.

Comment 31

[Richard Newman [:rnewman]]

(In reply to comment #30)
> bookmarks on the bookmarks toolbar in 3.6.12 will not change style or give me a
> tooltip on hover if firefox is not active.  (Richard, can you double check
> 3.6.12?)

I see the same behavior as you for that case for a fresh 3.6.12 profile.

However, I did get two other repro cases:

* Hold Cmd.
* Hover over a bookmark on the bookmark bar. Tooltip appears.
* Hit Tab to switch to Finder. Tooltip remains active.

Mouse position might be important here -- in some cases the tooltip disappears if you move the mouse and Firefox is still under the cursor.

... and a really awesome different version of this bug:

* Start a drag for a long-titled bookmark in the bookmark bar. Don't move off the bookmark.
* Hit Cmd-Tab to switch to Finder.
* Hit Esc to cancel the drag.
* Release the mouse button. Finder will have focus, but the tooltip will appear from hovering over the bookmark.

Again, mouse position is important.

I haven't tested either of these two cases in Fx4. It certainly seems like someone with a good understanding of the various window events on the Mac needs to audit all this...

Comment 32

[edrazeba]

Attachment: Screenshot showing Firefox 5.0.1 tooltip intruding into foreground

This bug still persists in Firefox 5.0.1.

Not only do tooltips that were already displayed remain visible when you switch from Firefox to another app, they appear if the mouse strays into that region while Firefox is already in the background.

Comment 33

[Phil Schwan]

(In reply to comment #32)
> 
> Not only do tooltips that were already displayed remain visible when you
> switch from Firefox to another app, they appear if the mouse strays into
> that region while Firefox is already in the background.

Yes -- this is actually the far, *far* more irritating symptom (at least on Mac OS X), if anyone is keeping track.

Comment 34

[edrazeba]

Attachment: Adblock Plus tooltip intrudes into Transmission.

This screenshot shows Transmission in the foreground and Firefox 5.0.1 in the background. Moving the pointer around the Transmission Inspector window causes Firefox's tooltips to be triggered, such as Adblock Plus' very large tooltip, which appears via the Adblock Plus toolbar button.

Comment 35

[edrazeba]

Attachment: Google search tooltip intrudes into Transmission

This screenshot shows Transmission in the foreground and Firefox 5.0.1 in the background. Moving the pointer around the Transmission Inspector window causes Firefox's tooltips to be triggered. In this example, with the mouse pointer positioned over Transmission's "Options" ("gear") button, both Transmission's "Options" tooltip and Firefox's Google search box tooltip are presented at the same time, with one layered over the other.

It's _really_ annoying.

Comment 36

[edrazeba]

Attachment: Bookmark tool bar item's "mouse over" state has been triggered

BTW, this is not just to do with tooltips, although that is the most intrusive and noticeable aspect; with Firefox 5.0.1 in the background and Transmission in the foreground, as you can see from this screenshot the tooltip for a bookmark is triggered. However, you'll also note that the item's "mouse over" state has been triggered. When moving the pointer into the vicinity of the bookmark, the bookmark button's state changes first, and a moment later the URL tooltip appears.

Most other (real) buttons do not appear to be affected by this "mouse over" state change, just their tooltips appear. An exception to this is the "Open a New Tab" "+" button; when Firefox is in the background, the "+" button's "mouse over" state is triggered (and naturally its tooltip) when the mouse pointer goes into that region of the backgrounded Firefox window.

Comment 37

[David.P]

Firefox tooltips always on top of all windows and not going away until you restart Firefox  still happens in Firefox v.36.0

Comment 38

[Zac Spitzer]

This is still happening in 49.0.2 on Windows 10

if you drag a link with a tooltip, after you drop the link elsewhere, the tooltip appears and remains as a top level item on the desktop until you focus and then unfocus Firefox

Comment 39

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

The severity field for this bug is relatively low, S3. However, the bug has 8 duplicates and 15 votes.
:enndeakin, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 40

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 41

[Tristan Miller]

Still reproducible (and still extremely annoying) with Thunderbird 102.4.1 (64-bit) and Firefox 106.0.1 (64-bit) on GNU/Linux. When I'm multitasking, I need to manually minimize Thunderbird in order to prevent its tooltips from interfering from my work in other windows.

Not reproducible with SeaMonkey 2.53.14, so maybe this isn't a Core product issue after all, or maybe SeaMonkey has done something to override the bad behaviour. Maybe the Firefox and Thunderbird developers can see what SeaMonkey has done to fix the issue and implement the same fix.

Comment 42

[denis]

This 21 year old bug is still open. It is quite annoying, to be frank -- happens to me at least once per day.

That said, given its longevity, I'm kinda partial to let it be forever. It feels like a relic from the past.

Comment 43

[Gustavo A. Díaz]

Hi, still happening to me too (OS: KDE Neon 22.04).
Firefox v113.0.2

Comment 44

[Sean Buckley]

Still happening on Firefox 115.0.2 + GNOME 44.

I just browser-hopped back to firefox this week and this was one of the larger annoyances, as I trigger it constantly.

For people who find this page via search engine, like me, the solution I'm using is to disable tooltips entirely, with the setting browser.chrome.toolbar_tips. It's a weird thing to have to resort to, but I don't think there's really any situation where I'll miss them.

Comment 45

[fanzhuyifan+github]

I am also experiencing this bug.

Version: firefox 117.0, clean profile; also thunderbird 115.2.0. Using xfce with xfwm.

Steps to reproduce:

Hover mouse over element that will generate tooltip.
Just as the tooltip is a about to appear, but before the tooltip appears, use hotkey to switch to another workspace.

Symptoms:
The tooltip will appear in the other workspace, and will not disappear until I switch back to firefox and move my mouse.

Comment 46

[fanzhuyifan+github]

Attachment: Bug 148624 - only show tooltip when document has focus. r=mstange,cmartin

Comment 47

[fanzhuyifan+github]

(In reply to fanzhuyifan+github from comment #45)

I am also experiencing this bug.

Version: firefox 117.0, clean profile; also thunderbird 115.2.0. Using xfce with xfwm.

Steps to reproduce:

Hover mouse over element that will generate tooltip.
Just as the tooltip is a about to appear, but before the tooltip appears, use hotkey to switch to another workspace.

Symptoms:
The tooltip will appear in the other workspace, and will not disappear until I switch back to firefox and move my mouse.

Reproducing the bug on firefox-nightly, on linux, xorg, xfce with xfwm.

Updated Steps to reproduce:

• Hover mouse over browser element that will generate tooltip (e.g., task bar. not webpage elements with tooltips)
• alt-tab to another window or use quick key to switch to another workspace

Comment 48

[Markus Stange [:mstange]]

I think a better fix would be for widget to send a window-level mouse exit event when the workspace switch happens. But I'm not sure where that code would go or how we would detect this situation.

Comment 49

[fanzhuyifan+github]

The nodes are already getting focusout events when workspace switches. This means some part of the code must already be detecting this situation, right?

Comment 51

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8ae372dc88d1
only show tooltip when document has focus. r=emilio

Comment 52

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/8ae372dc88d1

Comment 53

[fanzhuyifan+github]

For me the bug only shows up when MOZ_ENV_XINPUT2 is set to 1. The bug disappears as soon as MOZ_ENV_XINPUT2 is set to 0.

Comment 54

[Sylvestre Ledru [:Sylvestre]]

Seems that you made a lot of people happy:
https://framapiaf.org/@[e-mail]/111191271386263724

Comment 55

[Emilio Cobos Álvarez (:emilio)]

(In reply to fanzhuyifan+github from comment #53)

For me the bug only shows up when MOZ_ENV_XINPUT2 is set to 1. The bug disappears as soon as MOZ_ENV_XINPUT2 is set to 0.

That's bug 1809029. I can't repro but fixes are welcome.

Comment 59

[Ina Popescu, Desktop QA]

I've reproduced this issue using Firefox 106.0.1 on Ubuntu 22.04 following the STR from Comment 0.
Verified as fixed on the latest Nightly 120.0a1 version under same configuration where the issue no longer persists.

Comment 60

[Kai Engert [:KaiE:]]

Ryan, what do you think about uplifting to 115 ?
I've been running a local Thunderbird 115 with this patch applied, and it's been working fine for me, and the bug is fixed.

Comment 61

[Ryan VanderMeulen [:RyanVM]]

I don't think this is a good uplift candidate, no.