Closed
Bug 156764
Opened 22 years ago
Closed 22 years ago
Interface hangs after clicking onto a tooltip
Categories
(Core :: XUL, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: chtephan, Assigned: jag+mozilla)
References
Details
Attachments
(2 files)
3.82 KB,
patch
|
hewitt
:
review-
|
Details | Diff | Splinter Review |
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.
Updated•22 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•22 years ago
|
||
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•22 years ago
|
||
*** Bug 181069 has been marked as a duplicate of this bug. ***
*** Bug 187929 has been marked as a duplicate of this bug. ***
Comment 5•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
I rectify: it happens to me ALWAYS (this is more than very very often).
Comment 9•22 years ago
|
||
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
Comment 10•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
I'm seeing this a lot too. Setting to blocking1.3b+
Flags: blocking1.3b? → blocking1.3b+
Comment 13•22 years ago
|
||
Related to jkeiser's checkin on 1/21 for bug 185889 and 185965 ?
Comment 14•22 years ago
|
||
*** Bug 131409 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 15•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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.
Updated•22 years ago
|
Attachment #113105 -
Flags: review?
Comment 18•22 years ago
|
||
could the patch here also take care of bug 113536?
Keywords: nsbeta1
Target Milestone: M1 → ---
Comment 19•22 years ago
|
||
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•22 years ago
|
||
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?
s/should/showed/
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+
Attachment #113598 -
Flags: approval1.3b?
Assignee | ||
Comment 25•22 years ago
|
||
Comment on attachment 113598 [details] [diff] [review] fix in nsViewManager::GrabMouseEvents sr=jag for what it's worth. Thanks dbaron!
Comment 26•22 years ago
|
||
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
Comment 28•22 years ago
|
||
*** 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.
Description
•