156764 - Interface hangs after clicking onto a tooltip

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Christophe Saout]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Looks like bug 155018

Comment 2

[Greg Schafer]

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.

Comment 3

[Christopher Curzio]

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

Comment 4

[R.K.Aa.]

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

Comment 5

[Peter Henderson]

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.

Comment 6

[Vincent Lefevre]

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?

Comment 7

[Daniel Clemente]

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.

Comment 8

[Daniel Clemente]

I rectify: it happens to me ALWAYS (this is more than very very often).

Comment 9

[Daniel Clemente]

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.

Comment 10

[Jeremy M. Dolan]

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.

Comment 11

[Peter Henderson]

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).

Comment 12

[Asa Dotzler [:asa]]

I'm seeing this a lot too. Setting to blocking1.3b+

Comment 13

[Brian Ryner (not reading)]

Related to jkeiser's checkin on 1/21 for bug 185889 and 185965 ?

Comment 14

[Mike Kaply [:mkaply]]

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

Comment 15

[jag (Peter Annema)]

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).

Comment 16

[Joe McCabe]

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.

Comment 17

[Shotaro Kamio]

Attachment: change MouseDown event to MouseClick event

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.

Comment 18

[sairuh (rarely reading bugmail)]

could the patch here also take care of bug 113536?

Comment 19

[Shotaro Kamio]

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 20

[Joe Hewitt (gone)]

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.

Comment 21

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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 22

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: fix in nsViewManager::GrabMouseEvents

Comment 23

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

s/should/showed/

Comment 24

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

I think this is the right thing to do.

Comment 25

[jag (Peter Annema)]

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

sr=jag for what it's worth.

Thanks dbaron!

Comment 26

[Asa Dotzler [:asa]]

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

a=asa (on behalf of drivers) for checkin to 1.3beta.

Comment 27

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Fix checked in to trunk, 2003-02-05 15:10 PST.

Comment 28

[R.K.Aa.]

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