Introductory remarks: This bug has been driving me crazy for about a month, and I've been expecting someone else to report it and it to get fixed. But that doesn't seem to have happened. Either that, or I can't find it. I can reproduce the problem 100% of the time on Linux (on both a release build and my own build) but not Windows (on my own build). On windows, the tooltip in question never shows up. I'll try to test branch builds shortly, but so far I've just tested trunk builds. Synopsis: When I right click on a link that has a TITLE attribute (which thus gives it a tooltip), usually to open that link in a new tab, the tooltip pops up when I hover over the New Tab item on the tooltip. Once that happens, the chrome in the window becomes completely insensitive to mouse events. (This includes all UI buttons, menus (I think), context menus, and clicking on the tabs. It includes lack of any :hover/:active feedback.) However, I can still do anything in the page that I want to, and I can still use keyboard shortcuts to open / close windows, so it's not *quite* a dataloss situation for me. (It might be for a less savvy user.) Steps to reproduce: 1. load this page 2. right click on this link: bug 22274 (Bugzilla gives it a title. That's why I run into the problem so often.) Don't drag, just click. 3. Move the mouse down over the "Open link in new tab" item in the context menu, which is the second item in the context menu. 4. Wait for a tooltip to appear. Actual results: Tooltip appears. Once it does, all the chrome in the window is insensitive to mouse events, as described above. Expected results: No tooltip. No problems. Bug occurs in: * Linux release build, .tar.gz, 2002-06-27-08-trunk * my own trunk Linux optimized build (gcc 2.96 on RH 7.3), pulled evening of Jun 26. Bug does not occur in: * my own Windows gmake optimized build, pulled evening of Jun 28.

I can also reproduce this in 2002-06-29-07-1.0 Linux branch build (.tar.gz).

I found another workaround, actually: if I hover over the link again, after making the context menu go away (by clicking in the page), and the tooltip shows up, then things work again once the tooltip goes away.

Oops, I bungled the steps to reproduce by omitting the last Steps to reproduce: 1. load this page 2. right click on this link: bug 22274 (Bugzilla gives it a title. That's why I run into the problem so often.) Don't drag, just click. 3. Move the mouse down over the "Open link in new tab" item in the context menu, which is the second item in the context menu. 4. Wait for a tooltip to appear. 5. left-click on the tooltip.

dup of bug 113536?

I don't think so, but it looks like a bunch of bugs that this is a duplicate of have incorrectly been marked duplicates of it. This is also a more recent regression than that, and is also not reproducable on Windows.

Hmm. Perhaps it's a recent regression because Bugzilla recently started using TITLE? Maybe it is a dupe, since bug 113873, bug 114093, an the more recent bugs (bug 138185 and later) also mention the freezing symptoms. Many of the others don't, which seems surprising. Nor does the bug that they're being marked as duplicates of, which seems like a major omission.

The regression here seems to be that the tooltip appears after you pull up the context menu. That started happening between linux builds 2002050902 and 2002051010.

backing out bug 140767 fixes this bug

David Baron: I suggest you reopen the "bunch of bugs" that "have incorrectly been marked duplicates of it" [bug 113536]

bug 147288 seems to be about the same thing

-> me. It appears that we're not dispatching a NS_MOUSE_EXIT event for the widget containing the anchor when the pointer is moved into the popup. This only happens just after you right-click to show the context menu -- if I move the pointer out of the context menu and then back in, I get a LeaveNotify and resulting NS_MOUSE_EXIT as expected. (The NS_MOUSE_EXIT will cause a mouseout to be fired out the anchor and we will cancel the tooltip timer).

It appears that in the process of the context menu coming up, we get an odd series of leave and notify events from gtk. The last event to be fired on the widget containing the anchor is a leave, so mLeavePending is set to false, so we ignore the leave we get when you move the pointer into the context menu.

Blizzard, this is pretty much what we discussed on irc. This makes us always fire enter and exit events on child windows.

blizzard? can you review this?

*** Bug 159941 has been marked as a duplicate of this bug. ***

Comment on attachment 90643 [details] [diff] [review] possible fix r=blizzard We need to let this bake on the trunk.

Comment on attachment 90643 [details] [diff] [review] possible fix sr=dbaron (I trust you and blizzard, and it seems to make sense locally.)

Checked in.

*** Bug 146836 has been marked as a duplicate of this bug. ***

I find it still reproducible in the newly released mozilla-i686-pc-linux-gnu-1.1-sea.tar.gz and the Red_Hat_7x_RPMS builds.

Wenzhuo: this was never check into the 1.1 branch.

*** Bug 176875 has been marked as a duplicate of this bug. ***

*** Bug 179540 has been marked as a duplicate of this bug. ***

This bug has reappeared (Build ID 2002122200, Linux/PPC). Could it be reopened?

Well, tooltips do not appear above context menus (as the summary says), but they still randomly appear/disappear (one can even have two tooltips at the same time at wrong places), which is a more general problem.

This is bug 185965 - a recent regression.

I've started seeing half this bug again -- I've managed to left-click on a tooltip and cause the UI freeze (for example, hover over the numbers above after "Bug 115018 blocks", and then move quickly to the tooltip and left click on it). However, I don't see tooltips come up above context menus.