User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b1) Gecko/2007110904 Firefox/3.0b1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b1) Gecko/2007110904 Firefox/3.0b1 Every time I close Firefox, regardless of what website I'm on, when I close all instances of Firefox it stays in my task manager for 5-10 seconds. If I click the Firefox icon to start it again it gives me an error that Firefox is already running. This only happens in Firefox 3, not when I use Firefox 2. I also tried disabling all extensions and plugins, and switching to the default theme, which all had no affect. Reproducible: Always Steps to Reproduce: 1.Start Firefox 2.Close Firefox 3.Start Firefox right away Actual Results: Error message, saying firefox its already running. Expected Results: Started normally.

"Expected Results" should be: Start without error aka normally

I've seen this as well. Is this a dupe?

It's mainly due to the expiration (cleanup) code in the places database. Performance has improved a lot since bug 402297, and there's is still more to do : bug 407286, bug 407124, ... Beta 2 will be a lot better.

Yeah, I saw this using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007121108 Minefield/3.0b2pre which is just post-beta 2.

Confirming (since Sam said he saw it even post beta 2) and changing severity down to "normal". Seth, Dietrich: this is an interesting corner case we hadn't considered. I'm all for putting cleanup work into the shutdown process, but we need to figure out a way to not throw this error when a user then tries to restart it. Why don't we treat this like we do when someone tries to open Firefox when it's already open (ie: open a new window, and maybe just block that UI until the cleanup on the places DB is finished)

fwiw, I first saw this trying to run Firefox 2.0.0.11 after shutting down the Minefield from comment 5. Opening a new window, as suggested in comment 6, isn't quite the same. That's a super, super corner case though. :)

(In reply to comment #6) > Confirming (since Sam said he saw it even post beta 2) and changing severity > down to "normal". > > Seth, Dietrich: this is an interesting corner case we hadn't considered. I'm > all for putting cleanup work into the shutdown process, but we need to figure > out a way to not throw this error when a user then tries to restart it. We should actually do these same cleanup tasks on idle as well, to reduce the amount of work done on shutdown. > > Why don't we treat this like we do when someone tries to open Firefox when it's > already open (ie: open a new window, and maybe just block that UI until the > cleanup on the places DB is finished) The user might be restarting after installing an extension or security patch.

We should be able to get better wording on this. Not a new bug, should be much harder to hit after Firefox 3 b2 with the new expiration bits.

I don't see this actually after restarting Firefox (with a restart button). I see the problem only on my 512 MB RAM AMD Athlon Windows XP laptop but not at all on a much faster 2048 MB RAM Intel Dual Core Windows Vista laptop. A lot of people don't feel the need to buy a faster and more expensive computer or only maybe after some years. Performance of Places has improved a lot however. Dupe of bug 399108?

(In reply to comment #9) > We should be able to get better wording on this. Not a new bug, should be much > harder to hit after Firefox 3 b2 with the new expiration bits. It's pretty easy to hit if you accidentally close a window (no tabs) and immediately click on the Minefield quick launch icon. As I said in comment 5, I see this post-beta2. (In reply to comment #10) > Dupe of bug 399108? I'm okay with duping it if we feel that's the natural "fix" for this bug.

Thinking aloud... can't we just keep the item in the task bar until shutdown is complete? Then it looks like the app is still open (since it is). I've seen other apps do this even when their last window is closed.

Bug still occurs in Beta 2. Although it takes a few less seconds to leave the task manager.

Renominating based on the fact that the performance updates don't seem to have fixed things. Bob - how long does it stick around, and what's your system config? (resolution might be to morph to a string change)

bob, are you configured to clear private data on shutdown? in bug #409872, dietrich recently suggested that if places appears to be at fault (as we do some non-trivial queries on shutdown), we might want to treat restart different than quit, to avoid the delayed restart. however, if the user was going to manually quit and manually start up, that's something else.

On a AMD 3000+ 2 ghz processor, 2 gb ram and vista shutdown time varies from 10-30s. I have restore my windows and tabs from last time set. 21 MB places file

It sticks around for approximately 2-4 seconds. My pc is an AMD Sempron 3100. 1 GB of ram (it only say 896 MB). I have an 80 GB HDD but I've only used 9 GB. @Seth Spitzer: I have NOT selected private data to be cleared on shutdown.

Opps, I forgot to add its 1.8 GHz

Not a blocker. Possible solutions: - leave it in the task bar - add a "Try again" button to the profile locked warning

What's about an icon in the system tray? I've talked to some firefox3-beta2 users. Some of them has such a browsing behavior: They have lots of firefox windows with lots of tabs open, which they close, time to time. So it's a problem when the last window is closed and they want to start a new window immediately (for example from an email client). For such users slow shutdown is very uncomfortable. They also think, it's a bug. A firefox tray icon would continue to keep an app instance open, while the users would be able to close and re-open browser windows. Or is it too late to integrate such feature until the release of 3.0?

I think if people click the top right red Windows close button they really want to close this window and if this is the last window, they want to close the browser. The fact that they want to open it again soon after closing can have multiple reasons. Maybe it's their way to get rid of 55 open tabs, or the browser is consuming a lot of memory, and they see closing as a solution, or maybe they realised that they forgot something like uninstalling an extension or mailing to aunt Nelly. I think a permanent running minimized-to-tray Firefox is not what they have in mind when they decide to close. A temporary minimized-to-tray Firefox is not very discoverable. I'd vote for just a message on the "Firefox is running" message which makes clear that Firefox is still in the procedure of closing, but that it has understood the command and will open again as soon as possible.

I'm betting this isn't an issue anymore for builds after 01/09/2008 since bug 408914 landed. Anyone care to verify this for me, because I'm not seeing this anymore. If someone is still seeing it, could you dtrace it perhaps and see if it *is* places?

I'm still getting 25+ sec delays with my modestly large bookmarks stash. Still a problem.

Minefield/3.0b3pre ID:2008020304 PII 350MHz w/768Mb RAM - W2K-SP4 Watching the Windows Task Manager > Processes tab: places.sqlite = 3756KB bookmarks.postplaces.html = 2711KB 59 seconds for firefox.exe to close with a fresh Profile with only the default bookmarks in it 02 seconds for firefox.exe to close Ed

I used to get this after I imported my large bookmarks.html file and then closed Firefox, but I don't get this anymore. For the people who see this, does this happen after a bookmarks import? Are only the amount of bookmarks the cause of this problem? Or is it something in the profile that is cause? I guess it would be ideal if someone who experiences this, could make their profile (or part of it that causes the issue) available (only do this if you're comfortable with this).

Re - Comment 25: I see the delay over and over again, long after bookmark import. I see it with a clean profile long after bookmark import. Because I am developing my themes for fx3, I have to restart it many times. There is no change at all in the shutdown delay.

(In reply to comment #26) > Re - Comment 25: > > I see the delay over and over again, long after bookmark import. I see it with > a clean profile long after bookmark import. Because I am developing my themes > for fx3, I have to restart it many times. There is no change at all in the > shutdown delay. > Martijn's point is that large numbers of bookmarks being written at shutdown *due to a recent import* may cause the shutdown delay. That may have contributed to shutdown slowness before async IO was removed from mozStorage, however I'm betting it's just HTML export at this point.

I actually believe this to be a blocker now, as it can cause a bunch of undesirable behaviours - hopefully the bookmark export change planned for beta 4 will fix it, but we need to keep it on the radar.

I'm glad I saw this bug. I've had to take to opening my System Monitor just so I can visibly see when the Firefox 3 beta (nightly I run) is actually closed so I can safely reopen it. I also have a rather large bookmark collection, although I'm sure not as large as others', and it can be a pain when I'm trying to do things but I need to close Firefox 3 just to get a fresh session so I can continue doing things in my browser.

(In reply to comment #21) > I think if people click the top right red Windows close button they really want > to close this window and if this is the last window, they want to close the > browser. The fact that they want to open it again soon after closing can have > multiple reasons. I will explain my usage to shed some light on why the 10 second delay is more than an annoyance. My work is mainly offline, and I double click on the HTML file names to see them in my Firefox (V3 beta 2, 1.7 GHz Celeron, 512 Mb RAM). Not wanting tabs, the easiest way is to close the window (click on X) and then click on the next HTML seen in explorer window. 10 Seconds is too long a delay to wait before opening the next file. And the often caused confusion of not seeing the prompted message under all else adds to a secondary irritations :) .

(In reply to comment #25) > I used to get this after I imported my large bookmarks.html file and then > closed Firefox, but I don't get this anymore. > > For the people who see this, does this happen after a bookmarks import? > Are only the amount of bookmarks the cause of this problem? Or is it something > in the profile that is cause? > I guess it would be ideal if someone who experiences this, could make their > profile (or part of it that causes the issue) available (only do this if you're > comfortable with this). > I have completely uninstalled my Firefox 3 beta 2 and then reinstalled it as a standard installation. Doing the same offline browsing of HTML files, see comment #31, the shut down delay decreased from 10 seconds (100% CPU usage) to seven seconds (100% CPU usage). Do you still need a profile? I used no external data of my own in this test.

Parkhideh, please try it with Firefox 3 beta 4: http://www.mozilla.com/en-US/firefox/all-beta.html or with the latest nightly build: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ It's not useful anymore testing with Firefox beta 2. I'm hoping the patch in bug 392193 would fix this (this might in fact be the same bug).

Please see the link below for builds that contain the patch in bug 392193. https://bugzilla.mozilla.org/show_bug.cgi?id=392193#c20

(In reply to comment #33) > Parkhideh, please try it with Firefox 3 beta 4: > http://www.mozilla.com/en-US/firefox/all-beta.html > or with the latest nightly build: > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ > It's not useful anymore testing with Firefox beta 2. > > I'm hoping the patch in bug 392193 would fix this (this might in fact be the > same bug). > From http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ I tried [ ] firefox-3.0pre.en-US.win32.zip 02-Apr-2008 06:48 9.6M without bookmarks (and then added my bookmarks); the shutdown time in both cases is under 3 seconds and about 25% CPU usage. Quite an improvement. Also during the 3 second shut down I could start another Firefox. No prompts showed up and Firefox did start. Good work folks :) .

Mine was under Firefox 3.0 Beta 5, if no one has tested Beta 5. I read some of the comments, and I do not have a bunch of bookmarks. (I have about 6, but they are all on the "Bookmarks Toolbar") However, I can not reproduce this error very often. Intel Quad Core 2.4Ghz 2GB Ram Windows XP Pro.

Running FF3 RC1...took OVER A MINUTE to close out, with CPU jumping up and down. This is with bookmarks and extensions.

Intel Dual Core 3.2 Ghz 4GB RAM Windows XP SP3 Still seeing this behavior! ~B

Happens for me also, with FF3 rc1 on WinXP sp3, quite often to be noticed (about once a day). Usually it takes more than 10-15 seconds to shut down the firefox.exe process. I have a relatively long list of bookmarks (200+).

Bumping this up! I usually run firefox for a long period of time. If with FF2 I would restart the program every couple of days with FF3 and the new memory cycles I don't restart it much. So.. a few days later I find it to occupy more than 1GB of Virtual Memory (my top was 1.4G). I hence shut it down and notice that it takes a few minutes (up to 5) to clean up. This is extremely annoying! Please note that a reverse splash is not a solution as no way I'll have something on my screen nagging for several minutes!

(In reply to comment #43) > Bumping this up! > >I find it to occupy more than 1GB of > Virtual Memory (my top was 1.4G). > For sometime I "felt" memory (RAM) loss during my work. But because after closing all applications the memory was back and correct, I didn't pay enough attention. OS: Win2000 Sp4; Firefox 3.0 released version: Worked for about three hours, using single TAB, but going in and out of web pages that some had popup windows. At the end I am short of 100 Mb of RAM. No other application running. So I confirm report #43. Garbage collector must not be running or returning the RAM back to the system. Closing Firefox returned all the RAM; delay in closing was not significant to note the difference.

(In addition to comment #44) I repeated the test. After Firfox gobbled additional 100 Mb, stopped the program. To my surprise the CPU usage was no different than other cases, but the return of memory was slow. It first returned the usual 30-40 Mb in three seconds, but then there was a delay of under 5 seconds and then started to return the rest of the memory. Now I can see why return of a Giga byte would take so long.

Some additional information: In the discussion between me and Twinkletoes here ( http://forums.mozillazine.org/viewtopic.php?p=4303635#p4303635 and following) indicates that one of the causes for the delayed shutdown can be hanging local loopback connections. As long as those local loopback connections are still open firefox will not shutdown. If you start to kill them (e.g. with TCPView) the shutdown will be much faster.

First to open firefox you must hold ctrl+alt+delete and process then click firefox and end process Firefox will open

Additional information: if firefox don't shut down follow Comment #51

This bug is still occurring in Firefox 3.0.4 [Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4]. It does not matter how long I wait until I restart Firefox, it still hangs in my Processes until I close it there. This is very irritating. When will this be fixed?

@Comment #51 Forcibly ending the Firefox process isn't a very good idea, I don't think there is a potential for data loss (don't quote me!) but it won't be good for start up performance, and the tasks that were being performed obviously won't be done. -- I take it from the current wording of the dialog there is no way of telling between a zombie/hang and in-progress shutdown; and that it would not be worth it to change this. If the other/old process finishes its cleanup or gets killed before the dialog has been acknowledged, the startup of a new instance should procceed and the dialog go away. The current behaviour makes sense - where if "OK" is pressed, the new Firefox terminates, I think. If all else fails the wording of the current dialog... is not so wonderful. What was once probably considered an edge case can now be a regular occurrence of a recommended restart!. I suggest something more along the lines of "Firefox is still cleaning up from last time! Please wait for a moment - your session will be created shortly. If this takes too long, please log off and then on again or restart you computer." If that is too relaxed (hey, it's 4am where I am) perhaps: "Firefox is waiting for a previous instance to close, if this does not happen, try restarting your computer." (not completely happy with either, but a message would do well to indicate that Firefox is less likely hung and more likely just cleaning up.) Phew, longest post yet :0 ;) Hope this helped.

First time I've posted a bug report. I'm having same problem as Lady Aleena. It would be good if this problem could be fixed, rather than simply glossed over with an error message.

I am a bug FF fan since version 1 but am most disappointed by the lack in progress with this problem. For me this is a major problem and my FF in fact is blocked almost every time a close it and I need to use the Task Manager to "kill" it.

Still not a blocker - comment 58 sounds like a very different bug, and we should be monitoring/minimize the amount of time it takes to shut down. Tquit benchmark, anyone?

I cannot really say if i "found" the right bug when looking up my problem but this is the closest to what i was able to find when searching for it. What seems very important to me: - This is definitively something new in FF3. FF2 did not suffer from anything like this. - When looking at the task manager, FF actually also consumes a lot of processing time (around 30-40% of the total) while doing "nothing" and therefore suggests to somehow loop or wait for something. I would be most happy to contribute anything to the solution of this problem and make FF even better then is currently is.

My guess is that this issue is related to SQLite. Some kind of SQLite db processing going on at firefox shutdown is taking a while. This would make sense of reports that shutdown is longer when the browser has been open a long time. Perhaps a solution would be to have FF force this processing at various intervals so it doesn't all have to be done on shutdown.

This bug should be higher than a P4. More like a P2. When the Firefox process is running after "quitting" (as shown in XP Task Manager) my entire system grinds to a halt. The only way to prevent my system from slowing down is to be sure to remember to open up my task manager after quitting and killing the process manually. I use login services on my XP, and when I forget to kill the Firefox process manually and I later need to log in to my system it takes *forever* for the login to reveal the text input for logging in, and the system hangs for a long time until I can call up the task manager. Once I kill the Firefox process, everything is fine again. Please escalate this bug to a higher priority.

Follow up on #64: XP: Version 5.1.2600 Service Pack 2 Build 2600

I'm really surprised that this bug seems to only bother me. In my impression it's areal showstopper and a reason to move away from FF. This should be a P1 bug.

I agree with comment #66 , this bug should be higher priority. It causes users (the technical users, the others who don't know how to do this have to suffer) to have to press CTRL-ALT-DEL to bring up the task manager, every time they shutdown firefox, in order wait and see when it really closes, and only then re-open firefox. As suggested by others, Firefox should have a visual cue - at least show a closing screen or be minimized in the tasks bar until it really closes.

Hm, so a common use case (close window; open a new one) causes a big, verbose, unhelpful error message. This is progress? I don't expect Firefox to do anything at shutdown except... you know... shutdown. If it needs to export something to somewhere, it should do that when the thing changes.

Maybe it's time to file a new, separate bug for this and hope it doesn't get flipped as a duplicate. In my system (see comment #65) the process hangs, not for 5 minutes, but until I go into task manager and explicitly kill the process. If I forget to do that, like I did last night, when I wake up the computer it takes forever to reveal my login screen. In addition, I can't perform any other task once I do finally log in, because the Firefox process is eating up so much memory. Once I kill the process, I regain control of my computer. P1.

(In reply to comment #69) Chuck, this bug that you are reporting is different than the original bug that I saw on this report. This bug is reported as: Bug 275783 Java causes ghost Firefox process to remain after closing Unfortunately while the reports of the "ghost" are on this page, the Bug 275783 was put on Status RESOLVED INVALID due to lack of new sightings. :) I will put a message there to encourage them to read the new reports here, in case some one is still awake. A little bad news, Bug 275783 was opened in 2004, and is still with us.

You can of course read the comments in Bug 275783; but let me ask the following to see how correct is my comment #70. 1) Do you see the problem only if you browse a site that has JAVA applet? 2) When the problem happens and you go to the task manager: a) You see Firefox.exe (you should) ?! b) Do you also see Java.exe ? 3) If the answer to 2b) is yes; then a) do you see one or more Java.exe tasks? b) if you kill all the Java.exe tasks; does Firefox.exe also disappear? 4) So much for my experience. But someone in the know should be able to tell me if Firefox, before shutting down, attempts to close Java.exe and then waits for it to happen. I am guessing that it is waiting and because Java.exe is not closing then Firefox remains indefinitely in RAM.

Is this really Windows only?

I do not think so but I'm not 100% sure if sometimes there might also have been a java.exe process running. I do know that "killing" FF in the Task Manager solves the problem in 100% of the cases.

I don't think it is related to java as the problem happens with me when I haven't been to many sites (and the java console doesn't load up), it is more that I have opened and closed the main window several times and then it stops closing properly.

We need to escalate this bug. I say "we" as if I have contributed to this amazing browser, so let me just say that, yes, Mozilla/Firefox is as close to God as I will ever get, but, still, the damn process hangs, and there is no correlation to a javac process. I will say that with build 2009021910 Firefox/3.0.7 I think I haven't had the issue. But I'm not sure. And if I do, I'll be **** again, cuz it will mean that I forgot to kill the process in task manager, etc, yada yada. I think the looksee into a javac process was not a bad idea, but the leak is somewhere else, imho. Probably in C code pointer ****.

(In reply to comment #71) > You can of course read the comments in Bug 275783; but let me ask the following > to see how correct is my comment #70. > 1) Do you see the problem only if you browse a site that has JAVA applet? > 2) When the problem happens and you go to the task manager: > a) You see Firefox.exe (you should) ?! > b) Do you also see Java.exe ? > 3) If the answer to 2b) is yes; then > a) do you see one or more Java.exe tasks? > b) if you kill all the Java.exe tasks; does Firefox.exe also disappear? > > 4) So much for my experience. But someone in the know should be able to tell > me if Firefox, before shutting down, attempts to close Java.exe and then waits > for it to happen. I am guessing that it is waiting and because Java.exe is not > closing then Firefox remains indefinitely in RAM. "do you see one or more Java.exe tasks?" That's a silly question. I always have a java executable happening. Hello? Eclipse?

I might be being optimistic, but I haven't seen the problem since I upgraded to the latest version.

(In reply to comment #76) The answer to your silly question, with a proper English response, is "Yes, you do see one or more Java.exe tasks". For a complete report please look at [Bug 275783] Comment #144 and good luck. :)

(In reply to comment #75) > We need to escalate this bug. I say "we" as if I have contributed to this > amazing browser, so let me just say that, yes, Mozilla/Firefox is as close to > God as I will ever get, but, still, the damn process hangs, and there is no > correlation to a javac process. > > I will say that with build 2009021910 Firefox/3.0.7 I think I haven't had the > issue. But I'm not sure. And if I do, I'll be **** again, cuz it will mean > that I forgot to kill the process in task manager, etc, yada yada. > > I think the looksee into a javac process was not a bad idea, but the leak is > somewhere else, imho. Probably in C code pointer ****. First please note that the link Bugzilla placed under #144 above is for this page and not for bug 275783 page as it should be. Where should this be reported? :) ----- ------ ----- Next: OS Win2000, SP4; Java Plug-in 1.6.0_10-ea I had a bit of luck today by making an error and having array index overrun. Run this incorrect Java Applet: http://www.paperlessprocess.com/Firefox/Firefox_java.html This console output is the portable Firefox and works fine, which means it indicates some applet error and when closed, the console also disappears: version 1.5.0.7 Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7 Java Plug-in 1.6.0_10-ea Using JRE version 1.6.0_10-ea Java HotSpot(TM) Client VM User home directory = C:\Documents and Settings\Administrator ---------------------------------------------------- c: clear console window f: finalize objects on finalization queue g: garbage collect h: display this help message l: dump classloader list m: print memory usage o: trigger logging p: reload proxy configuration q: hide console r: reload policy configuration s: dump system and deployment properties t: dump thread list v: dump thread stack x: clear classloader cache 0-5: set trace level to <n> ---------------------------------------------------- IOException: java.io.FileNotFoundException: http://www.paperlessprocess.com/Firefox/stat/LogBook1.txt IOException: java.io.FileNotFoundException: http://www.paperlessprocess.com/Firefox/stat/LogBook2.txt java.lang.ArrayIndexOutOfBoundsException: 3009 at Call_html_v5.defineGraphics(Call_html_v5.java:597) at Call_html_v5.init(Call_html_v5.java:253) at sun.applet.AppletPanel.run(Unknown Source) at java.lang.Thread.run(Unknown Source) ------------------------------------------------- This is the Firefox 3.0 and does not work, which means the browser sits on the applet, no error and when closed, the console stays up: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 Applet status: Applet loaded. Applet status: Applet resized and added to parent container IOException: java.io.FileNotFoundException: http://www.paperlessprocess.com/Firefox/stat/LogBook1.txt IOException: java.io.FileNotFoundException: http://www.paperlessprocess.com/Firefox/stat/LogBook2.txt Exception in thread "thread applet-Call_html_v5.class-1" java.lang.ArrayIndexOutOfBoundsException: 3009 at Call_html_v5.defineGraphics(Call_html_v5.java:597) at Call_html_v5.init(Call_html_v5.java:253) at sun.plugin2.applet.Applet2Manager$AppletExecutionRunnable.run(Unknown Source) at java.lang.Thread.run(Unknown Source)

(In reply to comment #74) > I don't think it is related to java as the problem happens with me when I > haven't been to many sites (and the java console doesn't load up), it is more > that I have opened and closed the main window several times and then it stops > closing properly. Win 2000, SP4, Firefox 3.0 I want to confirm the comment #74. I was able to see the Firefox stay in memory without using any Java web pages. The difference in my case from #74 was that: 1- I had created many tabs (13 all together, with closing and opening some in between); but stayed with one Firefox window without closing it. 2- On closing the Firefox window, CPU usage went to 99% and stayed there.

That looks more like bug 474699. Probably both are related or bug 474699 is a dupe.

OS Win2000 SP4, Firefox 3.0, Internet connection Dialup I came across this condition accidentaly: - Dialup connection to ISP. - Firefox browsing few sites using multiple tabs. - Other application windows open, all local. - Going back and forth between applications and Firefox windows. - Closed Firefox window. - Some applications left open. - Had a new need for Firefox and started it again. Message came up Firefox is already running! - No indication on Taskbar. - Used Task Manager and saw Firefox.exe listed under processes. - Iconized all windows and saw the DIALER window hidden under all. I must have been disconnected without knowing. - Back to the Task Manager and saw the dialer. Stopped the dialer and Firefox.exe disappeard. - So similar is this behavior to stopping Java.exe; reported in comment #71. An uneducated guess would be that Firefox waits for other processes to shut down and hangs when they do not disappear.

(In reply to comment #12) > can't we just keep the item in the task bar until shutdown is complete? (In reply to comment #67) > Firefox should have a visual cue - at least show a closing screen > or be minimized in the tasks bar until it really closes. Samuel Sidler and nivtwig@gmail.com, I've opened Bug 488809 (request for termination splash screen). It'll expose long termination time to any user, even to user who doesn't click short-cut of Fx immediately. So, developers usually don't want to do so... :-)

I see a similar long (20-30 second) delay after "Quit" but before the process has exited. Real memory consumption jumps by about 150MB (from, say, 320MB->470MB). A quick look with the debugger shows me that this is mostly or entirely happening inside a single sqllite query in nsNavHistoryExpire::ExpireAnnotationsParanoid(). I can put a breakpoint after the query and watch it not get hit until memory consumption reaches its peak and 20 seconds have gone by. Immediate after this, memory consumption drops rapidly and the process exits within about 5 seconds. Here's the middle of the stack trace around the problem: sqlite3.dll!sqlite3BtreeLeaveAll(sqlite3 * db=0x602285b8) Line 29832 C sqlite3.dll!sqlite3_step(sqlite3_stmt * pStmt=) Line 41273 + 0x18 bytes C sqlite3.dll!sqlite3_exec(sqlite3 * db=0x01007d48, const char * zSql=0x0012fa8c, int (void *, int, char * *, char * *)* xCallback=0x00000000, void * pArg=0x00000000, char * * pzErrMsg=0x00000000) Line 60363 + 0x6 bytes C xul.dll!mozStorageConnection::ExecuteSimpleSQL(const nsACString_internal & aSQLStatement={...}) Line 326 + 0x47 bytes C++ xul.dll!nsNavHistoryExpire::ExpireAnnotationsParanoid(mozIStorageConnection * aConnection=0x00000000) Line 896 C++ xul.dll!nsNavHistoryExpire::OnQuit() Line 230 C++ xul.dll!nsNavHistory::Observe(nsISupports * aSubject=0x00000000, const char * aTopic=0x00000000, const wchar_t * aData=0x60ce3b34) Line 4719 C++ xul.dll!nsObserverService::NotifyObservers(nsISupports * aSubject=0x00000000, const char * aTopic=0x60c4fc90, const wchar_t * someData=0x60ce3b34) Line 181 + 0xf bytes C++ xul.dll!nsAppStartup::Quit(unsigned int aMode=1) Line 312 C++ xul.dll!nsAppStartup::ExitLastWindowClosingSurvivalArea() + 0x975b5 bytes C++ xul.dll!nsObserverService::NotifyObservers(nsISupports * aSubject=0x00000000, const char * aTopic=0x60ce0074, const wchar_t * someData=0x00000000) Line 181 + 0xf bytes C++ xul.dll!nsXULWindow::Destroy() Line 549 C++

The Problem of impossible fast restart of Minefield is still reproducible. (a 2nd or 3rd start of Minefield while 1 or 2 MineFields are running still works fine ) - I used latest 3.6a1pre of 11.5.2009 5:47 - I also clear private data by setting about:config, urlbar.maxRichResults =0 - I also a big bookmark tree - I created a link for Minefield-Safe-Mode to realize a quick start - I am also using an old computer, slow processor etc. - I opened the TaskManager to watch the process - I started Minefield-Safe-Mode - I closed Minefield-Safe-Mode - I started Minefield-Safe-Mode - - first Minefield-Safe-Mode was still displayed in Taskbar) - - 2nd Minefield-Safe-Mode was added in Taskbar Now error message is displayed: FireFox s already running, but it is not responding. To open a new window, You must close ........ If I just wait a few seconds after closing Firefix/Minefield, then I do not get an error message, but can open another or restart MineField. If You do not want to allow another instance of Minefield while one is still closing, the message should be changed to: please reopen in a few seconds, Your other closing process is still busy. (I reported this bug so far in #444915)

(In reply to comment #85) > If You do not want to allow another instance of Minefield while one is still > closing, the message should be changed to: > please reopen in a few seconds, Your other closing process is still busy. The message is misleading. We have several situation when that happen. Another case is e.g. bug 278860.

(In reply to comment #85) > The Problem of impossible fast restart of Minefield is still reproducible. Was same dialog as one in bug 459638 comment #3 displayed? See also Dependency Tree for bug 278860. > the message should be changed to: > please reopen in a few seconds, Your other closing process is still busy. Bug 459638 comment #3 is for similar issue(for same or similar message/phenomenon), but that's for issue in different situation(different cause, -remote & -no-remote with same P: <prof_name> case). I recommend you to open separate bug, setting dependency to bug 278860 & this bug for ease of tracking, to keep this bug for issue of "Delayed shutdown makes it impossible to start Firefox immediately after exiting" only.

Same problem using Vista Home Premium/ADSL2+ Site being accessed using FF freezes Turn off FF Restart FF Get subject error message Cannot restart via Start button>Restart (does not work) Cannot cancel FF through Start Task Manager Press restart button on PC tower (wait eternity while PC closes and restarts) Restart FF

When I updated Java, I started getting this error whenever i would try to close FF: Error: TypeError: CC(cid) is undefined When I try to open FF again, it says that FF is not responding. If I try a second time, it works fine...

I see this under Windows 7 RC. FireFox 3.5.2

We don't need any additional information about who's seeing this bug at this time, I think it's pretty well understood. The issue going forward is: - how are we going to solve it - when are we going to solve it Not for Firefox 3.6 for sure, and at this point I don't think we'd even take a fix for the mozilla-1.9.2 branch. Dietrich, putting this on your radar for mozilla-1.9.3. I think there's two potential solutions: create a dialog that waits for Firefox to finish its shutdown stuff and offers a "try again" button, or just automate it entirely and have it say "waiting to clean up from last time." Spin off bugs should be filed against specific things that are known to cause the shutdown process to take a long time, with an aim towards speeding them up.

Fwiw, I don't think a shutdown dialog is the solution. Afiak, the cause of the problem is Places. Disabling history seems to have fixed the problem for me.

My problem (per comment #84) was resolved by doing an SQLite vacuum. A 30-45 second, disk I/O intensive, additional 150MB of allocated memory shutdown became a 2-3 second shutdown without discernible memory allocation or disk usage. I don't recall the vacuum operation taking anywhere near 35-40 seconds, so had Firefox been clever enough to schedule this every so often it would have saved me substantial time and frustration. I agree that a dialog box is not the way to go. A browser should never allow itself into a state where it requires more than a few seconds to shut down.

The Places activity at shutdown that is likely the cause is expiration of history, and some database cleanup queries. There's a plan to remove that activity from the shutdown path for 3.7: https://wiki.mozilla.org/Places:Plan#Make_Expiration_async_and_performant

I've noticed that shutdown still takes a while whenever there is heavy usage of flash or java (perhaps any plug-in). Will the work in places effect this?

work in Places can only affect bookmarks and history shutdown.

When Firefox is running, it is possible to open a 2nd Firefox-Process. Don't know why You do not just open a 2nd Process while first is still shutting down, however long shutting down + cleaning history etc. might take.

Multiple instances accessing the same profile at the same time was a really long way away (hard) non-goal, last time I checked. (somewhat related to bug 101169?) Could it be possible to offer the option of running with a temporary profile - ie. in private browsing mode - until the real profile becomes available? *thinking out loud*

(In reply to comment #99) > When Firefox is running, it is possible to open a 2nd Firefox-Process. > Don't know why You do not just open a 2nd Process while first is still shutting > down, however long shutting down + cleaning history etc. might take. When I start a second Firefox window when an existing window is open there is still only one Firefox process. Have you verified there is a second process or are you assuming there is a second process since there is a second window?

In reply to Comment #101 I can open several instances. You can check it in the task manager, as well as in task bar and on the screen. Always worked that way. I can send You a screen-short. It is so on both my PCs. On Vista with Firefox 3.5.2 and XP with 3.5.2 It's nice to do so if You work on 2 Screens.

Please stop spamming this bug with comments which are not helpful to fix this bug. You can open or join a discussion on support.mozilla.com to continue your conversation. Thanks.

This problem is caused by a fundamental flaw in Firefox 3 Bookmarks. A simple solution is to remove the Bookmarks from Places. (That's the approach used by Google Chrome. Unlike Firefox. it does NOT use up to 240 MB of RAM when you close the browser, and you can close it instantly! It uses SQLITE only for Histry, not for Bookmarks. Bookmarks are saved in a format similar to Bookmarks. JSON. Moreover, the file does NOT include: a. Favicons b. Bookmark Description, which is typically very long and useless! Thus, Google Chrome can import/export Bookmarks very quickly and does NOT require several minutes of EXREMELY high memory usage during shutdown.) Mozilla Firefox design team has only two options: 1. Introduce a new LITE version, without SQLITE, like K-Meleon or Orca or 2. Redesign PLACES database by moving the bookmarks to a SEPARATE Bookmarks.JSON file, preferably without favicons or bookmark description field, both of which dramatically increase the size of the bookmarks file.

see comment 103

(In reply to comment #104) > This problem is caused by a fundamental flaw in Firefox 3 Bookmarks. > A simple solution is to remove the Bookmarks from Places. This issue has nothing to do with bookmarks being in places, but thanks for asserting your opinion as fact.

To help the Firefox designers see the extent of the shutdown problem I am attaching interesting memory statistics herewith. Computer: Pentium 4, 2.0 GhZ. 512 MB of RАМ A large bookmark.html file: 10 MB Firefox v3.5.3 memory consumption AFTER the program is closed Note: Snapshots were taken using every ten (10) seconds using: PsList 1.26 - Process Information Lister Copyright (C) 1999-2004 Mark Russinovich Sysinternals - www.sysinternals.com Here are the results: PsList -m Usage Summary a. All memory values are displayed in KB. b. Abbreviation key: Pid Process ID VM Virtual Memory WS Working Set Priv Private Virtual Memory Priv Pk Private Virtual Memory Peak Faults Page Faults NonP Non-Paged Pool Page Paged Pool ------------------------------------------------------------- Name Pid VM WS Priv Priv Pk Faults NonP Page firefox 4044 257780 134112 137160 179368 460450 23 101 firefox 4044 257780 132372 134732 179368 460945 22 101 firefox 4044 276212 171832 174120 179368 470802 23 101 firefox 4044 338676 234316 236612 237792 486408 25 101 firefox 4044 386804 164308 179788 291608 502608 27 101 firefox 4044 388852 207944 223440 291608 513517 27 101 firefox 4044 263880 75580 83568 291608 532877 22 99 As you can see Firefox exhibits virus-like behavior, using HUGE amounts of RAM, after it is closed. Google Chromem, which does not use SQLITE for its bookmarks shuts down instantly and does not use huge amount if RAM, even with a very large bookmark file.

Stop complaining about bookmarks in sqlite, that's not the problem unless you profile it. Google Chrome would not be able to manage so many bookmarks as we are exactly for the same reason, and using json to store bookmarks is not, and can't be, faster, reasons are clearly different. You are comparing apples with melons and saying melons are bigger. Please stop posting "me too" comments unless you have fired up a profiler and you can point out to specific points of our code that are causing the slowdown, that is the ONLY way to help fixing this bug. That said, if you want to provide useful data you could at least use current firefox 3.6 nightly since that's the version being worked on, and provide those data in a new discussion in mozilla.dev.apps.firefox newsgroup.

This problem no longer exists in Firefox 3.6b1. It still appears only if the user has started the bookmark export. Otherwise, there is no significant delay when the Firefox 3.6b1 is closed. Paradoxically, Firefox 3.6b1 beta is MUCH more stable than the last official release 3.5.3.

I have tried Firefox 3.6b1 on an older, slower computer with 256MB of RAM. Unfortunately, the problem still exists on slower systems with limited amount of memory. I could not shutdown the computer due to the Firefox process still running for several minutes. On the same computer, Google Chrome 4 Beta runs flawlessly.

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv

In light of comment 103, I thought it was still important to add my latest observation. I had not experienced this issue for some time until Out Of Process Plug-ins were enabled by default. I experience this issue quite frequently now when I have one or more of the mozilla-runtime.exe process(es). BUILD: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20100131 Minefield/3.7a1pre (.NET CLR 3.5.30729) ID:20100131043113 ~B

(In reply to comment #93) > Dietrich, putting this on your radar for mozilla-1.9.3. I think there's two > potential solutions: create a dialog that waits for Firefox to finish its > shutdown stuff and offers a "try again" button, or just automate it entirely > and have it say "waiting to clean up from last time." I believe the right approach here is to stop doing the work, which we've been doing. The last step of this is likely bug 552023. This does not block the release of Firefox 4.0

I'm glad there are votes on this feature. I have talked to about 4 other people in real life who also can't stand the "Firefox is already running" dialog boxes either. I have switched to Chrome along with another friend of mine as this exact "bug" was the proverbial straw for us, among other things. I've mentioned this on the #firefox IRC channel only to have someone accuse me of wanting to remove functionality. Well, I haven't suggested removing anything nor do I suggest something drastic here, other than perhaps a few developers brain-storming about how to do away this annoying message. In my opinion, a good step in the right direction (not a complete fix, however), would be to a button that says "Re-try" or "Try again" next to "Close" button so you don't have to keep wasting your time trying clicking "Close" and then clicking your favourite Firefox icon to keep trying to restart it.

When you have low memory, this is caused entirely by Firefox having to unpage the memory from the disk. It is apparently doing a lot of individual reads and writes rather than loading significant parts into memory and then using them. The problem with OOP is similar: two processes inevitably take up more memory than one. Plus, the reason Firefox tends to use so much memory in the first place is the plugin system. Flash, in particular, has poor behavior in keeping too much in memory, even when not in use. (You can verify this by manually disabling the plugin and watching the memory usage drop in both both firefox.exe and plugin-container.exe) While this is significantly better in Firefox 4, due to due to better implementation of OOP and better memory management, it still comes up any time Firefox's memory exceeds the amount of free physical memory available. It's just that this happens less often. I do second the request for a retry button, or even an active monitor that can poll every so often until Firefox can load again. A force quit button would be interesting, but probably not a good idea for people who would not realize they may lose data (such as Firefox button placement and bookmarks that haven't been backed up.) A separate extension/application could handle the force-quit functionality.

Sorry for the bugspam, but I forgot one thing: The profile already in use error should probably be different. If firefox.exe is not in memory, then no amount of waiting will unlock the profile. If a retry button is implemented, and it waits for firefox.exe to exit memory, it also needs to unlock or offer to unlock the profile. Oh, and sorry if this should be a separate bug. I'm still pretty new to bugzilla.

Rafael is working on this in 662444

Bug 662444 will reduce the amount of work performed upon File->Quit, but I don't see how it will fix either a Places bug or a startup bug.

(In reply to Jesse Ruderman from comment #120) > Bug 662444 will reduce the amount of work performed upon File->Quit, but I > don't see how it will fix either a Places bug or a startup bug. fwiw, the only thing Places does on shutdown are: - some cleanup but only if the user requested to clear history on shutdown - a bookmarks backup, but only if it was unable to make one on idle, in the last 24 hours - finalize prepared statements - merge the remaining journal in the database file (max 512KB) and close the connection This bug has been wrongly used for a long time as a catch-all-shutdown-bugs-and-blame-places, it's likely we need a real tracking bug in some more generic component, with actual telemetry data and real dependencies Apart some known and uncommon slow cases, that will be fixed along the way to async apis, there isn't useful data here.

Yeah I don't think this is a places bug(unless it's something like 684513), just a slow shutdown bug blocking startup. We can open a new bug if a similar issue is found once we exit(0).

This bug seems to be fixed since all the latert releases of Firefox. I do not see it happening any longer.

This problem still exists in Firefox 10 Beta! I suspect that it is caused by Firefox handling of the Bookmarks database. I have a very large Bookmarks file. Firefox probably updates the SQL files during shutdown. The JSON file is updated automatically only during the first Firefox use during the day.

(In reply to geos651 from comment #124) > I suspect that it is caused by Firefox handling of the Bookmarks database. Is this based just on guessing? do you see the problem disabling all add-ons? > The JSON file is updated automatically only during the first Firefox use > during the day. Yes, the update is done on idle, so shutdown shoulnd't matter. Do you have autoExportHTML set to true in about:config?

(In reply to nivtwig from comment #67) > I agree with comment #66 , this bug should be higher priority. > ............... > > As suggested by others, Firefox should have a visual cue - at least show a > closing screen or be minimized in the tasks bar until it really closes. For almost three years I did not see this problem. Now on Firefox 7.0.1 the problem of not releasing memory has occurred, but with a twist: 1- Firefox was running with NetBean IDE version 7.0 which is a memory hug. 2- Over a period of several hours I "felt" response was slowing down but attributed it to memory swaps. 3- Finished my work Closed NetBean, much of the memory came back. 4- Closed Firefox, without paying attention to memory. 5- Then noticed the response was still sluggish when looking at say file manager. 6- Noticed a missing 160 M bytes of memory. 7- From task manager I saw Firefox happy and well; using 160 M bytes, CPU usage zero. 8- After five minutes, Firefox was still there. 9- From task manager killed the process. 10- Memory was returned, sluggishness gone. This is my view; if someone as familiar with this problem as I has forgotten, and Firefox can do it and cause confusion; what reaction do we expect from other users. Why is there so much resistance to the idea of a "visual cue" requested in comment 67 and before? My opinion this minute is that Firefox designers are taking an amazing approach in visual cue. They have refused to place the online/offline visual indicator where it can be seen (like in Thunderbird); but have placed the STATUS line (Used by JAVA heavily) in the context area mixed with all the displayed browsing material (and jumps when mouse is placed on it, so no luck in copying the message). It makes me wonder if they consume their own creation?! I apologize for the spam but will not retract it. :)

There's a reason why this is marked as a resolved duplicate. The original bug is currently rather active--they are actively working on fixing this. It's more complicated than you'd think--they're on their sixth bug report, meaning six things they've had to change in order to make this happen. It is difficult to shut down Firefox while making sure it doesn't lose data. And I'm sorry for the bugspam, but I want to make sure everyone else on the CC list knows that someone has addressed this, so they don't wind up writing their own message that says essentially the same thing.

(In reply to Terrell Kelley from comment #127) > There's a reason why this is marked as a resolved duplicate. The original > bug is currently rather active--they are actively working on fixing this. > It's more complicated than you'd think--they're on their sixth bug report, > meaning six things they've had to change in order to make this happen. It is > difficult to shut down Firefox while making sure it doesn't lose data. > > And I'm sorry for the bugspam, but I want to make sure everyone else on the > CC list knows that someone has addressed this, so they don't wind up writing > their own message that says essentially the same thing. Reducing closing time in the taskmanager is very important but Terrel Kelley is saying that it seams that solving this bug is not easy and is taking a lot of time, BUT at least they could do something for now so when you want to re open firefox instantly after you closed it the browser opens at the same time that the firefox process that we opened early is still working.

Just to let all know that this problem is alive and well in Firefox 10.0. Terrell, would it be unkind of me to ask, if the problem can not be resolved in four years, couldn't the chunk of code that caused it be rolled back?

After four years, that would be more work than what they are currently doing. There have been a lot of changes since then. Firefox really isn't even the same browser.

10.0.2 the bug still occurs.