371405 - Tooltips only really work once; content tooltips not dismissed correctly

Status: VERIFIED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Boris Zbarsky [:bzbarsky]]

BUILD: Trunk Firefox build from today

STEPS TO REPRODUCE:

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.

Comment 1

[Jesse Ruderman]

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

Comment 2

[Jesse Ruderman]

Regressed between 2006-11-16 and 2006-11-17 nightlies.

Comment 3

[Jesse Ruderman]

Regression from bug 356528?

Comment 4

[Jesse Ruderman]

Regression from bug 356528 (confirmed by local backout).

Comment 5

[Josh Aas]

hwaara - any ideas here?

Comment 6

[Håkan Waara]

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.

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(We clarified this in the channel, but just for the record, Camino's content tooltips are its own/native.)

Comment 8

[Dave Townsend [:mossop]]

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

[Håkan Waara]

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: http://mxr.mozilla.org/seamonkey/source/widget/src/cocoa/nsChildView.mm#1310)

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

[Håkan Waara]

Sorry, that should be:

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

Comment 11

[Josh Aas]

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

Comment 12

[Josh Aas]

This is fixed by bug 376811. However, there is another underlying bug that caused this one, bug 378645, which we still need to fix.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Verified fixed in current nightly.