618733 - Tooltips should not show for background windows

Status: ASSIGNED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Jesse Ruderman]

Steps to reproduce:
1. Open Firefox's Find bar.
2. Position a TextEdit window so it covers the top of the "Highlight all" button.
3. Place the cursor over the exposed portion of the "Highlight all" button.
4. Quickly flick the cursor up into the TextEdit window.
5. Wait 500ms.

Result: A tooltip appears, far from where the mouse cursor is now, and doesn't go away until I interact with it.

Expected: A tooltip should not appear.

Comment 1

[Dominic]

Same thing here. Only applies to window elements (toolbar buttons, tabs, addons) but not to titles inside the content.
There is an option to completly disable tooltips in about:config:
browser.chrome.toolbar_tips
But this disables content-titles too!!! Not ideal.
A fix is needed...

Comment 2

[Alex Limi (:limi) — Firefox UX Team]

Yup, looks like we're showing tooltips from inactive Firefox windows on the Mac, which we shouldn't do. I've seen these "stuck" tooltips a lot of times, but couldn't reproduce, thanks for adding instructions.

Josh or Markus, any idea if this is an easy fix? Can we add a conditional check in the tooltip code to ensure that they only trigger when the window is active?

Comment 3

[Markus Stange [:mstange]]

The bug that Jesse reported is a regression from bug 130078 and I was going to fix it in bug 596600 (which describes the underlying issue). Basically, mouse out events are broken in certain cases at the moment; if they were working, the tooltip would only appear if the mouse was actually resting on the associated button, not just when passing over it. And the tooltip would disappear correctly as soon as the mouse moved far enough.

Disabling tooltips on background windows completely seems like a drastic step to me. Native Mac apps seem to be inconsistent in this respect: For example, Safari doesn't spawn tooltips on background windows, but Finder does.

Comment 4

[Dominic]

(In reply to comment #3)
> Native Mac apps seem to be inconsistent in this respect: For example,
> Safari doesn't spawn tooltips on background windows, but Finder does.

Not for me (Finder). Tested it with nearly every app on my mac. Only Firefox does it. It is so annoying :(

Comment 5

[Markus Stange [:mstange]]

Okay, I've tested some more apps and agree that those allowing tooltips on background windows are definitely in the minority.

(In reply to comment #4)
> Not for me (Finder).

Are you on 10.5? Maybe it only happens since 10.6.

Comment 6

[Dominic]

10.6.6 - All updates.
I use a Mac since the release of 10.5 and never noticed such a behaviour from the finder.
I've tried to use some css in userchrome to get rid of them, but don't get all.
I was able do remove tooltips from the addonbar/statusbar & from tabs but no success on the "new tab" button, toolbar buttons (back, forward...) and other small stuff.
Is there a guide or something discribing which element is what?

Comment 7

[Alex Limi (:limi) — Firefox UX Team]

I haven't ever seen tooltips from inactive windows except from Firefox. I don't think it's a very useful (or expected!) function, so if it's easier to fix that way, I think we should do it.

Comment 8

[Markus Stange [:mstange]]

Attachment: wip

This changes both nsMouseEvent and nsIDOMNSMouseEvent. Olli, are these interfaces among those that are already frozen for 2.0? If so, should I create new interfaces or should I wait until after 2.0?

This also needs a test, and I haven't run existing tests with it yet.

Comment 9

[Dominic]

Any news on this?

Comment 10

[Markus Stange [:mstange]]

Nope, and I'm also not sure how to proceed.

Olli, can you answer my questions in comment 8? Or maybe you have ideas for a different approach?

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

All the interfaces are frozen for 2.0, so nsIDOMNSMouseEvent is frozen.
And mozOnBackgroundWindow is strange. Why would we want to expose that to
web content?

When the tooltip is about to be shown, couldn't you just check whether
the tooltip is for the active window or any of it descendant windows (you can get top level active DOM window from focusmanager)?

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

So could you check whether the target of the event is in
active window in nsXULTooltipListener.cpp

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

Perhaps nsFocusManager could have a helper method
PRBool nsFocusManager::InInActiveWindow(nsINode* aNode);

Then that could be used in nsXULTooltipListener::MouseMove
and also in nsXULTooltipListener::ShowTooltip() if the window gets
de-activated after nsXULTooltipListener::MouseMove.

Enn, does that sound ok to you?

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

Oh, and since this behavior is platform depended, the check in nsXULTooltipListener should perhaps use some pref, which is set true only on
OSX. (Though, I don't know what behavior is expected on Windows)

Comment 15

[Dominic]

sorry for bumping, but this is so annoying :(
A fix is needed

Comment 16

[d.a.]

Looks like this happens on WinXP too, see bug 631462.

Comment 17

[orangezilla]

(In reply to comment #16)
> Looks like this happens on WinXP too, see bug 631462.
Also Windows 7, presumably Vista also.