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)
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 =)
Comment 1•16 years ago
|
||
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
Reporter | ||
Comment 3•16 years ago
|
||
Sorry for the duplicate, had some issue with submitting the first =)
Comment 4•15 years ago
|
||
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.
Comment 6•15 years ago
|
||
Which build are you seeing this in, Justin? Bug 527748 and bug 527657 landed just before the 20091212 nightly and should have fixed it.
Comment 7•15 years ago
|
||
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.
Comment 8•13 years ago
|
||
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.
Comment 9•9 years ago
|
||
My reproduction no longer words. (Hooray.)
Comment 10•9 years ago
|
||
err, works
Updated•8 years ago
|
Flags: needinfo?(twalker)
Comment 11•8 years ago
|
||
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.
Description
•