Closed Bug 156764 Opened 18 years ago Closed 17 years ago
Interface hangs after clicking onto a tooltip
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.
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
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.
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.
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: 17 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.