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)

Product:
Core
Component:
Widget: Cocoa
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9beta2

People

(Reporter: jruderman, Unassigned)

References

Details

(Keywords: dataloss, regression, Whiteboard: [notacrash])

Attachments

(2 files, 2 obsolete files)

Python script Jesse used to reproduce the bug
3.05 KB, text/plain
Details
Possible fix rev1 (update for latest builds)
7.13 KB, 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.
> 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.
Flags: blocking1.9+
Assignee: joshmoz → smichaud
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.
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.)
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.
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.

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
I should have mentioned that I tested with the 2007-09-10-04 Minefield
nightly.

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

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

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.
Attached patch Possible fix (obsolete) — — Splinter Review 
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
Steven - does this patch need to be updated now that the new appshell is in?
Yes, it does ... though it might still apply with offsets.

I'll post a new one tomorrow.

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

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

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

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

I just had this bug happen to me on Mac OS X 10.5 9a559.
> 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?

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.
> 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.
Target Milestone: --- → mozilla1.9 M10
blocking1.9- for now, may reverse if we get more information
Flags: blocking1.9+ → blocking1.9-
Steven figured out some more in bug 436897.
Depends on: 436897
Whiteboard: [notacrash]
fwiw, the patch in bug 675208 did not fix this.
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.

Attachment

General

Creator:
Created:
Updated:
Size: