Closed Bug 409872 Opened 14 years ago Closed 7 years ago

Update taking 30+ sec to with no feedback


(Toolkit :: Application Update, defect)

Windows XP
Not set





(Reporter: raceronline, Unassigned)


User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20071127 Firefox/
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2007122405 Minefield/3.0b3pre

When taking an update (branch nightly), Firefox is taking 30-60 seconds between the time Firefox closes and the time that the "Software Update" window displays. During that time, I am left wandering if something went wrong with the update and if I need to manually start Firefox again. This happens with both full and incremental updates.

System: 1.9Ghz Pentium M, 1 GB RAM

Reproducible: Always

Steps to Reproduce:
1. Help->Check for Updates
2. Click Restart
3. Firefox process ends
4. Wait for anywhere from 30-60 seconds with no visual feedback (no significant CPU usage either)
5. Notice the "Software Update" window display, which indicates "Firefox is installing your update..."
Actual Results:  
Have to wait 30-60 seconds (step 4) to get visual feedback that everything is working as intended.

Expected Results:  
Wait under 5 seconds to get visual feedback.

I don't mind it taking a minute to update. However, when it doesn't notify me that it is still in the process of (waiting to begin) updating, there is no way to determine if it is even working. Five seconds is an arbitrary maximum, but it is a reasonable amount of time to wait before expecting some sort of feedback.

Example times:
I timed the updates in two scenarios:
1) Full update -- time without feedback: 47 seconds
2) Incremental update -- time without feedback: 54 seconds

Others have indicated similar times, although some have as low as 10 second delays.
Could you just confirm what you mean by "branch nightly" ? Your User-Agent is the release, but the Build-Identifier is a _trunk_ nightly (ie Minefield).

Some food for thought/testing:
* Is the behaviour reproducible with a blank profile ? 
* How long does Firefox take to leave the Process List of the Task Manager after you go File > Exit ? 
* Is that time consistent ?
* Is that time different when you do an update ?
I see the same thing with even the latest trunk.  Firefox takes approximately 20 seconds to leave the process list after I close Firefox, which I suspect is the reason for the long no indication that Firefox is updating or about to or whatever the heck it is doing.  I also have this same problem when I accidentally close Firefox and want to reopen it...getting the dialog saying Firefox is still open or whatever.  I think I remember reading before that Firefox is clearing/vacuuming something during this time (note: I don't have it set to clear any data though) but we should get some kinda of indication of this when we are in the middle of updating.

Maybe we shouldn't be doing this during update and then this bug wouldn't be any issue then?
Ever confirmed: true
Version: unspecified → Trunk
Sorry, I meant trunk nightly -- as in Gecko/2007122405 Minefield/3.0b3pre
Any feedback on the bullet points in comment #1 ? CC'ing the default places address.
Yes, could be history expiration work done by Places at shutdown. We've severely curtailed the amount of work done, but still is possible that it's the cause of this problem.

Is there a way to detect that we're going down specifically for an update, or because the user hit "restart" after installing an extension or theme? If so, Places could not do expiration work in those cases.
After looking more closely, most of the shutdown time is happening after the Firefox window is "closed" but before the process actually ends.

After the process actually ends, it takes around 5 seconds to bring up the Firefox window again.
Product: Firefox → Toolkit
No other reports and lots of things have changed with how Firefox shuts down so resolving wfm. If you are still able to reproduce please reopen.
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.