Closed Bug 392626 Opened 17 years ago Closed 17 years ago

Firefox.exe often not shutting down when JAWS is running


(Core :: Disability Access APIs, defect)

Windows XP
Not set





(Reporter: MarcoZ, Unassigned)


(Blocks 2 open bugs)


(Keywords: access, regression)


(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv: Gecko/20070725 Firefox/
Build Identifier: trunk

Often, when surfing web pages, then closing Firefox down, a Firefox process remains in Windows Task Manager. The process cannot be ended, one has to reboot the computer. Side effects of this are that all subsequent launches of Firefox behave inconsistently and result in many rendering errors for JAWS. I have observed this with Minefield builds, but never with Firefox 2.0

Reproducible: Sometimes

Steps to Reproduce:
1. Start JAWS 8.0 and Minefield.
2. Visit bugzilla pages (that's where I've often seen it happen).
3. Close Minefield.
4. Open Windows Task Manager (Control+Shift+Escape).
5. Verify: On the Applications page, Firefox is no longer listed.
6. Verify: A Firefox.exe process may or may not be present on the Processes page.
7. If it is present, highlight it, then click End Process.
Actual Results:  
Often, the window disappears, and Firefox is no longer listed in Windows Task Manager's Applications page, but on the Processes page of Task Manager, a Firefox.exe process is still running. When clicking End Process, Windows Task Manager will complain that Firefox.exe process cannot be terminated.

Expected Results:  
Firefox.exe process should completely go away from Task Manager, and no need should be to manually end its process.

Windows XP Home Edition SP2 all updates, IE 7 is also installed.
Assignee: nobody → aaronleventhal
Component: Disability Access → Disability Access APIs
Keywords: access, regression
Product: Firefox → Core
QA Contact: disability.access → accessibility-apis
Blocks: keya11y
Flags: blocking1.9?
I haven't been able to duplicate this so far.
It's still my constant companion. I almost everytime see it when going to It has ads that may cause this to happen, some have Flash, others don't, but there are a lot of inline frames displaying in any case.
Blocks: ia2
No longer blocks: keya11y
I've seen firefox.exe left open before in the task manager, so that I could not launch a new Firefox because of it. However, I was able to kill the process.

When I run JAWS, then launch Firefox 3 with and then quit Firefox, I do not get this problem.  I tried several times.

Does it do anything strange when you try this with Firefox in the debugger? Perhaps there is some infinite loop at the end (Ctrl+Alt+Break will let you stop and get a stack). Perhaps the console log will tell us something.

I may have found a way to repro this:
1. Open Minefield. Mine automatically goes to the Minefield start page
2. Go to
3. If you're not already logged in with your accunt, log in. I am automatically logged in on this computer.
4. Click on the EitanISaacson link.
5. The next page comes up where you are given options to edit the page etc.
6. Close Firefox.

If I have JAWS running, the Firefox.exe process hangs every time for me.
(In reply to comment #4)
> I may have found a way to repro this:

I can't duplicate that.  I checked Task Manager immediately after I shut down Minefield and the process was not to be found.
Severity: major → critical
Blocks: fox3access
Marco, can you reproduce this reliably enough to get a regression range?
I was able to duplicate Marco's results using his steps in comment 4, but only once.

The time that it happened Firefox also had tried to install a partial update, and failed.
I've also been able to duplicate this twice with this bugzilla page, but then went about 5 times without it happening.

One difference is that I have no problem killing the Firefox process afterwards, but I'm not sure that's important.
(In reply to comment #6)
> Marco, can you reproduce this reliably enough to get a regression range?

Unfortunately not. Like you've found out yourself, this thing comes and goes at its leisure. :-( Even the page I mention in comment #4 does not cause it to happen often enough that I would call it reliable.
Marco, does it always happen the first time you follow your steps after a new system log in or a reboot?
(In reply to comment #10)
> Marco, does it always happen the first time you follow your steps after a new
> system log in or a reboot?

Unfortunately no. I just tried five times, and it wouldn't happen anytime. Earlier today, I got hangs four times in a row with different sites. This one is really illuding us!
Even though I'm not able to repro this 100%, the steps given in comment #4 are still my best bet. I just reproduced it five out of six times.
One thing that might be important: I'm using the JAWS Links List (Insert+F7) to get to the "EitanISaacson" link.
Okay. Keep trying to get reproducable steps please. I can't think of too many more important bugs for us to fix than this one, and I need help with it.
Yes, the Insert+F7 could be important. If you get repro 5/6 times that sounds good enough to find the day it broke.
Currently, it does not repro for me at all any more, even with builds that are after the day I reported the bug originally.
However I am noticing something starting with 2007-07-01 build: If I shut down this build, or any build after that, I get a slight crackling in my soundcard, as JAWS speaks the window I land in after Firefox closes. This does not happen with any prior build. The only other time I hear this crackling in speech is when my CPU is busy doing something and I try to get JAWS to speak. It's like a slight spike in CPU usage that then rapidly drops.
The checkins in this period are:
Anything looking even remotely suspicious?
Marco, I was just browsing with ff3 and did not run JAWS, but the firefox.exe was left hanging around. I notice a couple of other similar bugs are open and CC'd you on those.

I guess it's possible to attach a debugger to the process, after this happens, to get a stack. But, are you running a build that has symbols?

It's probably worth asking the other testing gurus on #qa what to do. Maybe it's possible to send the process a crash signal so that the crash reporter comes up.
(In reply to comment #16)
> I guess it's possible to attach a debugger to the process, after this happens,
> to get a stack. But, are you running a build that has symbols?

No, I have never seen these hangs with a debug build. To me, this appears like some sort of race condition that only gets exposed on release builds (where things happen much faster than on debug builds). I'll ask on #qa what options we have.
I am now trying to get the hang reproduced with WinDBG running my process. Hopefully I can catch it in the hang there and get a call stack. I'll post it once I get it, here.
Attached file Output from WinDBG.
I managed to get a hang once. When I then chose Debug->Break, I got the Warning... shown in the file. After that, I issued the "kp" command to get the stack trace, but I don't know if this is at all useful.
This is probably happening because of leaks. In fact we do leak, and need to fix that anyway. Perhaps if we look to the source of these leaks when running with JAWS we will fix this bug. It's a good starting point which we need to do anyway.
Depends on: 399195
Marco, since you are almost always running with JAWS, how do you know for sure that it's JAWS-related? Notice that Seth Spitzer has filed some similar bugs and he doesn't run JAWS.

See bug 400489, bug 386286 and bug 400704
Summary: Firefox often not shutting down when JAWS is running → Firefox.exe often not shutting down when JAWS is running
Depends on: zombieproc
I managed to get a debug build to hang. I then attached to that process using VS 2005, and when I did a Debug/Break All, I landed at this spot:

This is consistent with the WinDbg output I posted in an earlier comment.
Aha -- that's exactly where Seth is hanging in bug 386286. I now just noticed you mentioned that in that bug.
I still don't see a complete stack with symbols here.
OK, found the exact build this started happening for me. It's the build dated 2007-06-12-06, which is the first libXUL build. See bug 345517, which was checked in 2007-06-12 at 06:22 PDT. See also bug 386286.
Blocks: 345517
Benjamin, any ideas? This was caused by the change to libxul.
Assignee: aaronleventhal → bsmedberg
Assignee: bsmedberg → benjamin
Assignee: benjamin → nobody
Ever confirmed: true
Closed: 17 years ago
Resolution: --- → DUPLICATE
Blocks: zombieproc
No longer depends on: zombieproc
You need to log in before you can comment on or make changes to this bug.