Closed Bug 371405 Opened 17 years ago Closed 17 years ago

Tooltips only really work once; content tooltips not dismissed correctly


(Core :: Widget: Cocoa, defect)

Not set





(Reporter: bzbarsky, Assigned: jaas)



(Keywords: regression)

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?
Yes, this is pretty annoying.  It's been happening for months :/
Regressed between 2006-11-16 and 2006-11-17 nightlies.
Regression from bug 356528?
Keywords: regression
Regression from bug 356528 (confirmed by local backout).
Blocks: 356528
hwaara - any ideas here?
Flags: blocking1.9? → blocking1.9+
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.
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.
Sorry, that should be:

we set event->widget = parentWidget when a popup widget fires an event.
This appears to be fixed by my patch on bug 376811.
Depends on: 376811
This is fixed by bug 376811. However, there is another underlying bug that caused this one, bug 378645, which we still need to fix.
Closed: 17 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.