Tooltips only really work once; content tooltips not dismissed correctly




12 years ago
12 years ago


(Reporter: bzbarsky, Assigned: jaas)



Mac OS X
Dependency tree / graph
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)


BUILD: Trunk Firefox build from today


1)  Open two tabs.  Load two pages in them.
2)  Hover one of the tabs.  Wait for the tooltip to appear.
3)  Move the mouse out of the tab.  Watch the tooltip disappear.
4)  Move the mouse back into the tab

EXPECTED RESULTS:  Tooltip appears again.

ACTUAL RESULTS:  No tooltip.

Clicking somewhere makes things happy again.

With content tooltips (e.g. the dependency list in bug 177805), the tooltip doesn't even disappear in step 3.

This actually makes bugzilla pretty annoying to use on mac -- if I want to find the right bug in a dep list, I have to either load the dep tree page or keep clicking between tooltips.
Flags: blocking1.9?

Comment 1

12 years ago
Yes, this is pretty annoying.  It's been happening for months :/

Comment 2

12 years ago
Regressed between 2006-11-16 and 2006-11-17 nightlies.

Comment 3

12 years ago
Regression from bug 356528?


12 years ago
Keywords: regression

Comment 4

12 years ago
Regression from bug 356528 (confirmed by local backout).
Blocks: 356528

Comment 5

12 years ago
hwaara - any ideas here?
Flags: blocking1.9? → blocking1.9+

Comment 6

12 years ago
Is there a way to make Camino suffer from this? After all, it's using the same content tooltips (as far as I can remember). 

The answer to that question could give a clue about where to debug.
(We clarified this in the channel, but just for the record, Camino's content tooltips are its own/native.)
bug 355102 appears to have had some kind of impact here. Previously I would frequently see tooltips remaining on screen till clicking away. Now they seem to go away all the time, however now I am seeing the mouse pointer being fixed in whatever type it was when the tooltip appeared, so if I hover a link that makes a tooltip appear the mouse pointer remains as a hand wherever I move it on the screen.

Comment 9

12 years ago
Roc, Bz and Pavlov, please see below.

I found a fix to get tooltips working as they should, but it breaks contextmenus and popupmenus. As usual.

A question to gecko people: When a popup widget fires an event, we set event->eventStructType = parentWidget. Does this make sense? Shouldn't the originator of the event be the popup widget itself?

(See this line, where we enforce this:

The question is: Is this something that gecko wants us to do; do other widgets do this as well, or is it just a hack?

Pavlov added it to get contextmenus to draw (bug 332917). If I change the if-statement to only execute when event->eventStructType == NS_PAINT_EVENT then things actually paint. But other events are still broken in the contextmenus, and other popups.  That might be because we've wallpapered over this for a year, so other things need to be changed too?

The question I ask is because I've ended up at that line in the other cocoa widget bugs I've worked on (but still not solved), so I think it would be useful to understand.

Comment 10

12 years ago
Sorry, that should be:

we set event->widget = parentWidget when a popup widget fires an event.

Comment 11

12 years ago
This appears to be fixed by my patch on bug 376811.


12 years ago
Depends on: 376811

Comment 12

12 years ago
This is fixed by bug 376811. However, there is another underlying bug that caused this one, bug 378645, which we still need to fix.
Last Resolved: 12 years ago
Resolution: --- → FIXED
Verified fixed in current nightly.
You need to log in before you can comment on or make changes to this bug.