Closed
Bug 393664
Opened 17 years ago
Closed 10 years ago
When Firefox crashes in the background, other apps think the mouse button is held down
Categories
(Core :: Widget: Cocoa, defect)
Tracking
()
RESOLVED
FIXED
mozilla1.9beta2
People
(Reporter: jruderman, Unassigned)
References
Details
(Keywords: dataloss, regression, Whiteboard: [notacrash])
Attachments
(2 files, 2 obsolete files)
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review |
Almost every time Firefox (Mac trunk debug) crashes in the background, another app thinks that I'm holding the mouse button down. This happens immediately after the process goes away. It also happens when I force quit Firefox out of a hang. The location of the bogus mousedown isn't where the cursor is. Instead, it's usually something I clicked on recently, such as a dock icon or the content area of TextWrangler. When it happens on the dock, it's just annoying, but when it happens in TextWrangler, some random text gets deleted. This started happening a few weeks ago. CCing Steven Michaud because Colin Barrett thought Steven would enjoy this bug.
Comment 1•17 years ago
|
||
> CCing Steven Michaud because Colin Barrett thought Steven would > enjoy this bug. Yeah, I like wierd, twisted bugs with five heads and three legs ... sometimes :-) What most likely triggered this bug was the part of my "consolidated patch for issues with popup windows" (bug 387164) that started using "event taps" to get around a bad bug in Apple's "event monitors". But it turns out that event taps have even worse bugs. I've already stopped using event taps (and event monitors) in Camino, which doesn't need them (bug 389683). If at all possible, I'd like to keep using them in Minefield. But if event taps also cause bad problems in Minefield, I may have no choice. Anyway, the "consolidated popup patch" was landed around 2007-07-17 13:49:37 PDT. So the 2007-07-17-04-trunk and previous Minefield nightlies don't have the patch, while the 2007-07-18-04-trunk and subsequent Minefield nightlies do have it. Jesse, could you test with Minefield nightlies that do and don't use event taps, and see if this makes any difference? Or (if the problem only happens in debug builds) you could change my patch for bug 389683 so that it disables event taps and event monitors on both Camino and Minefield. This will cause bug 339945 (and possibly also other context menu problems) to start happening again in Minefield. But it'd be interesting to see if that makes this bug go away.
Comment 2•17 years ago
|
||
Here's a simple patch that disables event taps and event monitors everywhere, for people who want to test if disabling them makes this bug (or some other problem) go away.
Reporter | ||
Comment 3•17 years ago
|
||
I can reproduce in a 2007-07-18 nightly, but not in a 2007-07-17 nightly, supporting smichaud's theory. (It's hard to reproduce this bug at will, even with a python script launching Firefox with a crashing URL every 3 seconds, so I'm not completely sure about the latter.)
Reporter | ||
Comment 4•17 years ago
|
||
export MOZ_CRASHREPORTER_DISABLE=1 nt.py 120 "/Users/jruderman/builds/Minefield 2007-09-01.app/Contents/MacOS/firefox" Click around and type in TextWrangler while Firefox is crashing every few seconds. Sometimes typing will appear to do nothing until you click again; that means you've hit the bug.
Comment 5•17 years ago
|
||
Thanks, Jesse, for getting back on this. I'll try your Python script to see if I can reproduce your results. As I said before, though, if at all possible I'd like to keep using event taps in Minefield -- the alternative solutions to tracking context menus across processes are quite a bit clumsier. If I can find a way to reproduce this problem reliably enough, I may be able to come up with a tweak that gets around this bug in event taps.
Comment 6•17 years ago
|
||
Jesse, I finally had a chance to test out your Python script. I prepared a TextWrangler document by filling it with newlines. Then, while your Python script was running in the background, I rapidly did the following hundreds of times: 1) Left-clicked once somewhere in the document (either at the end of an existing line or on a new line). 2) Typed two or three letters. I did this first on my PowerPC G4 desktop, then on my MacBook Pro. In all these attempts I saw your bug exactly once (on my MacBook Pro): Typing more letters appeared to have no effect. But when I clicked on the desktop and back inside the TextWrangler document, the letters I had typed suddenly appeared. Unless I can find a more reliable way to reproduce this problem, I will face a very stark choice: I'll either have to leave things as they are or stop using event taps. Have you been able to come up with more reliable ways to reproduce this problem? Have you ever seen this bug on a build that didn't use event taps?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 7•17 years ago
|
||
I should have mentioned that I tested with the 2007-09-10-04 Minefield nightly.
Reporter | ||
Comment 8•17 years ago
|
||
> Have you been able to come up with more reliable ways to reproduce > this problem? I suspect these might reproduce it more reliably: - Killing Firefox during a hang. - Crashing a debug build of Firefox (rather than a nightly). I haven't tested, though. > Have you ever seen this bug on a build that didn't use event taps? No.
Comment 9•17 years ago
|
||
Jesse's Python script (attachment 279636 [details]), which is this bug's testcase, uses another bug's testcase (bug 378521, attachment 262566 [details]) to reliably crash Mac Firefox on the trunk. Jesse, do you have a testcase posted somewhere that reliably hangs Mac Firefox on the trunk? :-)
Reporter | ||
Comment 10•17 years ago
|
||
<script>while(1);</script> https://bugzilla.mozilla.org/buglist.cgi?quicksearch=reporter%3Ajrud+kw%3Ahang+kw%3Atestcase
Comment 11•17 years ago
|
||
> <script>while(1);</script> This works (embedded in an html file). But Firefox doesn't stay hung (because it periodically warns the user about an "unresponsive script" and asks if you want to stop it), so it's a little difficult to work with. I ended up using the test case for bug 394540 (attachment 279218 [details]) in most of my tests.
Comment 12•17 years ago
|
||
I found a somewhat fiddly but quite reliable procedure that triggers problems that (I hope) are good standins for the problem Jesse reported (which I still can't manage to reproduce reliably). You don't have to use a debug build (nightlies will do). And this procedure "works" (it causes problems) with builds that use event taps, while it doesn't "work" (it doesn't cause problems) with builds that don't use event taps. Furthermore I found a way to tweak the use of event taps so that this procedure no longer "works". So there's some hope that my tweak will also make Jesse's problem go away. I'll post the patch in my next comment. Anyway, here's my procedure: 1) Run Minefield and size its (single) browser window to take up about half the screen. 2) Run TextWrangler and size its single window to take up the other half of the screen. Then type some text in the window and triple-click on it (to select it). 3) Do something to make Firefox hang. 4) Click on the TextWrangler window's title bar to make it (and TextWrangler) active, without deselecting the text you selected in step 2. 5) Choose Force Quit from TextWrangler's Apple menu and force-quit Minefield, but don't close the "Force Quit Applications" window. 6) When the OS has finished force-quitting Minefield, the "Force Quit Application" window _should_ have the focus (though the focused app will still be TextWranger). And it will have the focus if your build doesn't use event taps. But if it does use event taps, the window focus (and possibly also the app focus) will be in a semi-broken state: a) The "Force Quit Application" window won't appear to have the focus (its title bar will be grayed). b) But the TextWrangler window (whose title bar isn't grayed) won't really have the focus either -- typing keys will produce beeps, and the formerly selected text will stay selected (and unchanged). This will keep happening even after you click once on the TextWranger window's title bar (though clicking twice or clicking in the "content region" makes the problem go away). c) Sometimes TextWranger's Apple menu will re-open after the OS has finished force-quitting Minefield. d) Sometimes TextWrangler window will "stick" to the mouse cursor the first time you click on its title bar -- it will get dragged around with the mouse even though you aren't holding down the mouse button.
Comment 13•17 years ago
|
||
Here's a patch that fixes the problems I talked about in comment #12, and with luck will also fix the problem that Jesse reported. It's quite simple -- it keeps the event tap disabled while the application is active (when the event tap isn't needed). Jesse, please try this out and let us know your results. If it works for you I'll ask Josh to review it.
Attachment #279614 -
Attachment is obsolete: true
Comment 14•17 years ago
|
||
Steven - does this patch need to be updated now that the new appshell is in?
Comment 15•17 years ago
|
||
Yes, it does ... though it might still apply with offsets. I'll post a new one tomorrow.
Reporter | ||
Comment 17•17 years ago
|
||
> It's quite simple -- it keeps the event tap disabled while the > application is active (when the event tap isn't needed). I'm not sure why you think this change will fix this bug, since this bug is about what happens when Firefox crashes while it isn't the active app. > Jesse, please try this out and let us know your results. It doesn't fix the bug for me.
Comment 18•17 years ago
|
||
> since this bug is about what happens when Firefox crashes while it > isn't the active app So it appears ... but there was always the chance the actual underlying problem was the app focus being in a "semi-broken state" (as I said in comment #12). That's why I asked you to test. Even though my patch doesn't fix your problem, I think it's worth landing on its own merits (there are some problems it does fix). I'll open a new bug on that subject. As for the problem reported here, I don't currently have sufficient information to reproduce it reliably enough to make it worthwhile testing any fixes (short of simply getting rid of event taps). I'm inclined to leave things the way they are for the time being, in the hope that either you (Jesse) or someone else will eventually come with a better STR for this problem.
Reporter | ||
Comment 19•17 years ago
|
||
Actually, I think this patch makes the problem worse :( Now, instead of affected apps getting a single bogus "mouse held down", they're failing to respond to keyboard shortcuts and clicks on the dock icon for a long time.
Comment 20•17 years ago
|
||
I'm beginning to wonder if there's some additional factor involved -- (presumably) some kind of software that you're running but I'm not. Since I wrote up my own STR in comment #12, I've started noticing bits and pieces of the symptoms from step 6 when I force-quit a Minefield build that doesn't have my patch (particularly the re-opened menu). But these are things my patch _does_ fix, which are presumably unrelated to your problem(s). Still, though, it may be best to put off landing my patch. The bottom line, though, is that there's nothing I can do without a better STR. It'd also be nice to see other reports of similar problems.
Comment 21•17 years ago
|
||
> they're failing to respond to keyboard shortcuts and clicks on the
> dock icon for a long time.
You know, I suspect whatever additional software you're running is
also using event taps. Furthermore I suspect that it's using them to
filter events (unlike Minefield which is only using them to observer
events).
If an event-tap-implemented event filter takes too long to filter an
event, the entire login session appears to hang. But the OS is
supposed to time out these "hangs" (according to Apple's docs).
Apple's docs don't say how long the timeout is, but that could explain
your "for a long time".
At some point I'll write a little terminal app you can use to find out
how many event taps have been installed, and what kind they are.
Comment 22•17 years ago
|
||
> You know, I suspect whatever additional software you're running is
> also using event taps. Furthermore I suspect that it's using them
> to filter events (unlike Minefield which is only using them to
> observer events).
Because event taps are so new, so poorly documented, and so buggy,
this "additional software" is likely to be Apple's. And because Apple
specifically loosens the security of keyboard event event taps for
accessibility software, this "additional software" might be related to
accessibility.
(Yes, we're only concerned with mouse-down event event taps. But this
security exception probably exists for the sake of Apple's own
accessibility software, which (therefore) presumably uses event taps.)
Comment 24•17 years ago
|
||
> I just had this bug happen to me on Mac OS X 10.5 9a559.
Could you describe what happened in more detail?
By any chance do you have steps to reproduce?
Comment 25•17 years ago
|
||
I was working on a patch with a debug build, my patch was causing crashes, after one crash I tried to drag'n'drop a file on the desktop and I couldn't let go of the file to drop it.
Comment 26•17 years ago
|
||
> I couldn't let go of the file to drop it So the file stayed "stuck" to the mouse even after you were no longer holding down the button? Sounds a bit like 6d from comment #12 ... which apparently _isn't_ the problem that Jesse has been seeing.
Comment 27•17 years ago
|
||
blocking1.9- for now, may reverse if we get more information
Flags: blocking1.9+ → blocking1.9-
Reporter | ||
Updated•15 years ago
|
Whiteboard: [notacrash]
Comment 30•10 years ago
|
||
This should probably have been fixed by the patches for bug 699538. Please reopen if that's not true. In any case I'll almost certainly never have time to do more work on this bug.
Assignee: smichaud → nobody
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•