User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4 (.NET CLR 3.5.30729) If Firefox has been running for a long time (hours... don't know how many... maybe a whole day) takes too long to shut down. By too long I mean somewhere from 1.5 to almost 3 minutes (maybe longer sometimes, but when I did a test with a watch, I got about 2 min and 45 sec). places.sqlite in my profile is about 65 MB, and other sqlite files are about 500 KB. However, I don't think this is an important factor because if I close Firefox shortly after starting it (say, seconds or a couple of minutes), its process exits within about 5 seconds. My computer has a dual core AMD CPU and 2 GB RAM. This is NOT a new issue with FF 3.5 beta. It has been going on for a long time with 3.0.x (I don't remember if I had this problem with versions before 3.0.x). Reproducible: Always
Maybe this problem has a common cause with bug 474699 and bug 450371. By the way, CPU usage during shutting down is around 50% (dual core CPU).
I forgot to mention that I usually have lots of tabs open. The last time (when I measured the time with a watch), I had about 50 open tabs.
This is a mass search for bugs which are in the Firefox General component, are UNCO, have not been changed for 500 days and have an unspecified version. Reporter, can you please update to Firefox 3.6.10 or later, create a fresh profile, http://support.mozilla.com/en-US/kb/managing+profiles, and test again. If you still see the issue, please update this bug. If the issue is gone, please set the status to RESOLVED > WORKSFORME.
Whiteboard: [CLOSEME 2010-11-01]
This still happens.
With a new profile?
Whiteboard: [CLOSEME 2010-11-01]
Version: unspecified → 3.6 Branch
I didn't try it with a new profile when I replied here a few minutes, but I've have created 2 or more new profiles in the recent past and have always observed this problem. This problem takes a good amount of time, as you may see from the description of the problem.
Any news about this problem ? I noticed this prob after updating to FF 4.01. Now I have updated to FF 5.0 and this problem persists. It's reproducable every time I use FF. Only one account is running on my PC. FF is active for several minutes after a long internet session, with up to 50 % load on one core (Intel Core i3 540 Quad Core, WIN XP SP 3). Looks like FF is running a defragmentation while deleting temp files? The non-responding time is proportional to the session duration. Longer sesions, longer HDD activity time. When I try to restart FF, the message "FF is already running ..etc) appears and I have to kill it by using the task manager. This can't be the solution! Please have this fixed.
(In reply to comment #7) > When I try to restart FF, the message "FF is already running ..etc) appears > and I have to kill it by using the task manager. Other users have run into this error message too. Firefox should display a window saying it's exiting, saving some data, etc. until its process is ready to quit.
This happens in the trunk version too.
This continues to happen in ff7 beta 1. I don't use any tabs, just open windows. If I have about 6 windows open (all Firefox) for about 20 minutes, when I close all of the Firefox windows and exit Firefox the shut down process takes about 30 seconds. I can hear the hard drive working during this time, what is it doing? The Firefox process should close immediately when the last window is closed.
Two months later, and in between I updated from FF 4.01 to FF 6.0. Still the same problem with shutting down FF after longer sessions. The dev team didn't spent any time solving this issue yet. What a pity ! And - this bug's status is still unconfirmed. What do you need to make it a confirmed bug ? 200 complaints ?
Still happening with FF 8.0 on MacOSX. I used to think it was deleting the cache. It seemed to be proportional to the number of pages visited. But as of 8.0, it's slow even after a start on a blank page, no activity, and then command-Q.
Same here. Version 8.0 shows the same bug as described. ALL: Please scroll up the page to 'importance' and give your voting. It seems that noboby will work on it unless the importance is high enough. Every vote will make it more important - and hopefully less annoying to us.
Same with version 11.0a1.
Still happens with version 12 on Snow Leopard. However, it's not as frequent on blank pages as it was previously. Sometimes, with no warning, there will be a 5 minute time to quit. During this time, the Mac Menu bar and Dock can be frozen, although clicking on the Desktop will change to the Finder. It's really hitting the file system hard!
Does this happen also after creating a new profile (see http://support.mozilla.com/en-US/kb/Basic%20Troubleshooting#w_8-make-a-new-profile and http://support.mozilla.org/kb/Managing%20profiles for more information)?
OS: Windows Vista → All
Hardware: x86 → All
Version: 3.6 Branch → 12 Branch
(In reply to Andre Klapper from comment #16) > Does this happen also after creating a new profile (see > http://support.mozilla.com/en-US/kb/Basic%20Troubleshooting#w_8-make-a-new- > profile and http://support.mozilla.org/kb/Managing%20profiles for more > information)? Hi Andre, haven't tried and I wont't do so. If creating a new profile each time Mozilla becomes **** for no obvious reason, it's not worth running it on a machine anyway. What a poor solution ... About the reported bug: This strange behaviour with long HDD access and delayed shutdown of FF was gone after update to FF14 and is still absent at version FF15. So, for the time being the bug has gone. Will it re-appear?
Since switching to using tabs and also switching to Mac OS X, I have not had this problem.
(In reply to gschelm from comment #17) > haven't tried and I wont't do so. In that case it's impossible to track down reasons. Closing this ticket as WORKSFORME.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
I'd like to request the reopen of this bug. I am using windows and I also/still have this problem.
You need to log in before you can comment on or make changes to this bug.