Closed Bug 427211 Opened 16 years ago Closed 8 years ago

Tooltips for address bar do not disappear when moving spaces

Categories

(Core :: Widget: Cocoa, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: james, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5

Hover cursor over address bar and before the tooltips appears, move to another space. The tooltip will appear in the other space.

Reproducible: Always

Steps to Reproduce:
1. However cursor over address bar
2. Before the tooltip appears, move to another space (use keyboard command as CONTROL and ARROWS)
3. Observe the tooltip for Firefox in another space
Actual Results:  
Tooltips appear in other space

Expected Results:  
Tooltips will not appear in other space

Video of error: http://muffindcc.com/vids/ff3-tooltips-error-addressbar.mov

Would be handy if you could remove the tooltips for the address bar entirely as its kinda pointless =)
I can confirm this, and it happens for any tooltip, not just the address bar.
Assignee: nobody → joshmoz
Status: UNCONFIRMED → NEW
Component: OS Integration → Widget: Cocoa
Ever confirmed: true
Product: Firefox → Core
QA Contact: os.integration → cocoa
Version: unspecified → Trunk
Sorry for the duplicate, had some issue with submitting the first =)
Assignee: joshmoz → nobody
Argh, this has been driving me crazy lately. Not sure why, but I hit this multiple times per day.

From a brief skim of the code, I suspect the cause it the slight delay between when the mouse finishes moving, and when we decide to show the tooltip. The only checks done after the timer fires are to see if the node is still in the document. So we won't notice if you're suddenly on another workspace.

See layout/xul/base/src/nsXULTooltipListener.cpp, nsXULTooltipListener::ShowTooltip().

From a quick test, it seems that on Windows 7 background apps (IE) will still display tooltip if you mouseover widgets. On OS X, background apps (Safari) will hilight widgets as you mouseover, but will not generate a tooltip. Not sure what Linux does offhand. I assume we want to match what the platform convention is on each?

Not sure how to create a virtual workspace on Win7, but clearly when the app is no longer on the screen we shouldn't be popping up mysterious tooltips for any platform.

I suppose the alternate way to fix this is to make sure that tooltips (and other popups?) always open on the same workspace as the app. So we'd still show the tooltip for this case in OS X, but you'd not see it because it would be on the right Space...
I thought maybe Markus's recent mousemoved stuff would fix this, but if dolske's still seeing it, I guess not.
Which build are you seeing this in, Justin? Bug 527748 and bug 527657 landed just before the 20091212 nightly and should have fixed it.
Ah! Why is it whenever I comment on something bugging me for a while, it turns out to have just been fixed? Indeed, with a freshly updated nightly, I can't seen to reproduce the problem. FWIW, the way I realized I'm hitting this is that I have an extra mouse button mapped to Show Spaces, so it's easy for me to very quickly move the mouse somewhere, hit that button, then click a space.

There's still one quirk, though. If I hover to let the tooltop show up, then switch spaces this way, as it zoom into the new space the tooltop flies in to the new space (and then immediately disappears). Ideally the tooltop shouldn't end up in the new space at all.
I can also reproduce this by using the hotkey-based app switcher Butler:

1. Trigger a tooltip in Firefox
2. Hit F5, which I have bound to switch to BBEdit.

The tooltip persists over top of the BBEdit window until I move the mouse.
My reproduction no longer words. (Hooray.)
err, works
Flags: needinfo?(twalker)
Mac 10.11, Nighlty 49.0a1, 20160504043118

I am unable to reproduce this, marking wfm
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(twalker)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.