Closed Bug 156764 Opened 22 years ago Closed 22 years ago

Interface hangs after clicking onto a tooltip

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: chtephan, Assigned: jag+mozilla)

References

Details

Attachments

(2 files)

change MouseDown event to MouseClick event
3.82 KB, patch
hewitt
: review-
Details | Diff | Splinter Review
fix in nsViewManager::GrabMouseEvents
1.17 KB, patch
roc
: review+
roc
: superreview+
asa
: approval1.3b+
Details | Diff | Splinter Review 
Sometimes, when moving the mouse to a bookmark in the personal toolbar, a
tooltip appears but doesn't disappear (maybe I'm too fast?). When I accidentally
click onto this tooltip it disappears but the whole UI "hangs" (can't click onto
any buttons or menu). Only the local window hangs, the only option remaining is
to close it and open a new one.
Looks like bug 155018
Depends on: 155018
Status: UNCONFIRMED → NEW
Ever confirmed: true
I am seeing this too. It may look like bug 155018 but I have applied the patch
mentioned in that report and it does not fix the problem here. I am seeing it in
the back button history thingo. Sometimes when clicking on an item to jump back
2 or 3 pages, a tooltip will appear right underneath the mouse and I end up
accidentally clicking the tooltip. From that point onwards the interface is hung
and I must exit the browser by hitting Ctrl-Q. This is mozilla-1.1 on
i686-pc-linux-gnu, gcc-3.2, glibc-2.2.5, binutils-2.13.
*** Bug 181069 has been marked as a duplicate of this bug. ***
*** Bug 187929 has been marked as a duplicate of this bug. ***
I think this is related to bug 113536. That bug hasn't been recently active so I
don't know its status.

A simple workaround is to find something with a tooltip. I think it has to be an
element in the page. Remember that (as long as the viewport has focus) you can
scroll with the keyboard and change tabs with the keyboard. Find some way to get
an element with a tooltip. Hover on that element. Then dismiss it normally (it
should go away by itself when you move the mouse, but if it doesn't--due to bug
185965--then click on an empty area of the page).

What I think is happening is the tooltip is absorbing all the mouse events (like
a menu does). The first click makes the tooltip disappear, but it doesn't
properly release the capture of the mouse events. With a menu, the first click
makes the menu disappear and it also releases mouse events, and then subsequent
clicks are passed on to objects that would normally receive a click. This
workaround makes another tooltip come back, and then makes it go away properly
so it stops capturing mouse events.
The described workaround in comment #5 doesn't work here (build 2003012222 under
Linux/x86).

Shouldn't the severity be set to "major", because one has to kill Mozilla when
the problem occurs?
I see it very very often with recent builds on Linux (currently using 2003012405). 
It's very annoying, it should be corrected before 1.3 IMHO.

I rectify: it happens to me ALWAYS (this is more than very very often).
100% reproducible (currently using Linux 2003012522). Interface always hangs.

Setting severity to 'major' and marking 'blocking1.3b'=?, as it is a very
important (and annoying) bug.
Severity: normal → major
Flags: blocking1.3b?
Target Milestone: --- → M1
I've been restarting Phoenix 6-7 times a day to clear this broken focus state
lately. I highly recommend 1.3b be held for this.
I've played around a bit more and it seems like my workaround only worked when
the tooltip I clicked was in the content area. If it's a chrome tooltip (e.g. on
the personal toolbar) then I haven't found a way to get back to a normal focus
state.

However, there is a way to avoid restarting Mozilla (or Phoenix). Whenever this
has happened to me, the keyboard has still worked. You can type Ctrl-N to open a
new window, then switch back to the old window and copy the address using Ctrl-L
and Ctrl-C, and then paste the address into the new window. Whenever I have
tried, I could still switch tabs too (Ctrl-PgUp and Ctrl-PgDn).
I'm seeing this a lot too. Setting to blocking1.3b+
Flags: blocking1.3b? → blocking1.3b+
Related to jkeiser's checkin on 1/21 for bug 185889 and 185965 ?
*** Bug 131409 has been marked as a duplicate of this bug. ***
seth: see comment 13.

One way to reproduce this is to get a tooltip to show up for a bookmark on your
personal toolbar, then get your mouse over the tooltip (you have to be really
fast for this it seems) and click it (though on MacOSX the click doesn't seem to
dismiss the tooltip, once the tooltip times out I get the same problem as
described here).
Another easy test case -

1) Move your window to the bottom of your screen
2) Hover your mouse over the "tools" icons on the bottom left (browser, mail,
composer, etc)
3) See if the tooltip materializes under the pointer - if not, move the window
down to the very edge of your screen and repeat
4) Click on tooltip that now displays under your pointer

This seems to work well since Mozilla will make every effort to not draw the
tooltip off the screen.
I found the interface will not receive any event after processed mousedown
event.
Trying to change MouseDown to MouseClick event, it seems to be good.
Attachment #113105 - Flags: review?
could the patch here also take care of bug 113536?
Keywords: nsbeta1
Target Milestone: M1 → ---
My patch has some relation to bug 113536.
Hanging as comment#19 or comment#41 of bug 113536 is suppressed by my patch.
But this patch dones not deal with clicking through a tooltip.
Comment on attachment 113105 [details] [diff] [review]
change MouseDown event to MouseClick event

This is the wrong way to fix this - tooltips should go away on mousedown, as
they do natively in Windows.
Attachment #113105 - Flags: review? → review-
I debugged what was going on here by locally backing out the patch on bug 155018
so that I could reproduce the bug using the steps there.

This should that the chrome document's view manager's mMouseGrabber is being set
from nsFrame::HandlePress, as if we're starting a selection.  However, this
seems to be happening *after* the tooltip has already been hidden by the event
handling code (what was being patched in the previous patch, I presume).  So the
grab is undone neither by nsFrame::HandleRelease (the usual way of ending a
selection) nor by nsView::SetTransparency, which attempts to enforce the rule
that transparent views can never be grabbing the mouse (which is a good thing
since they don't get any events).

I'll attach a patch that changes nsViewManager::GrabMouseEvents to check the
transparency on the view, and clear the mouse grabber instead if the view is
transparent.  (An alternative would be to do nothing, i.e., to return instead of
setting |aView = nsnull|.)  Probably a messier alternative would be to try to
fix the tooltip code so this won't happen.  (One easy way would probably be to
set -moz-user-select: none, but that seems a little fragile.)

So, any thoughts on this approach, or advantages of other approaches?
Comment on attachment 113598 [details] [diff] [review]
fix in nsViewManager::GrabMouseEvents

I think this is the right thing to do.
Attachment #113598 - Flags: superreview+
Attachment #113598 - Flags: review+
Comment on attachment 113598 [details] [diff] [review]
fix in nsViewManager::GrabMouseEvents

sr=jag for what it's worth.

Thanks dbaron!
Comment on attachment 113598 [details] [diff] [review]
fix in nsViewManager::GrabMouseEvents

a=asa (on behalf of drivers) for checkin to 1.3beta.
Attachment #113598 - Flags: approval1.3b? → approval1.3b+
Fix checked in to trunk, 2003-02-05 15:10 PST.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 194896 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: