(Note: this is filed as a meta bug as part of the “Paper Cut” bugs since we assume that there are multiple existing bugs related to this behavior. Please make them block this bug.) This obviously affects a lot of different things, including the https://wiki.mozilla.org/Firefox/Projects/Eradicate_Startup_Dialogs project and updater code across the different platforms. Recommendation: - Silent updates for add-ons, with possibility to enable explicit upgrade notices if you want (being handled in the https://wiki.mozilla.org/Firefox/Projects/Extension_Manager_Redesign project - Firefox updates should be applied on shutdown, never on startup (ideally in the background while using the browser, but that might be harder)
Depends on: 446342
Depends on: 481815
(In reply to comment #0) > - Firefox updates should be applied on shutdown, never on startup I assume provided that does not make Bug 561144 worst
I think it's a matter of perception. If we leave a window open with "Firefox is updating XYZ and will shutdown when done" then it will feel a whole lot less weird to see a "Firefox is already running" window when you try to start it. Right now, the problem with slow closing is that we kill the window right away so it FEELS gone but it's not actually.
The vast majority of times I get the "Firefox is already running" error it isn't due to update. We also open exclusively the firefox.exe file on Windows as of 3.6 when doing an update so that message won't be seen anyways. Also, on Windows a large percentage of users will get the UAC prompt so just applying on shutdown won't suffice and we'll likely need a service to perform the update silently which will be apply the update when no instances of Firefox are running for all users on the system along with a few more hoops to jump through and not on app shutdown so much.
(In reply to comment #2) > I think it's a matter of perception. If we leave a window open with "Firefox > is updating XYZ and will shutdown when done" then it will feel a whole lot less > weird to see a "Firefox is already running" window when you try to start it. > Right now, the problem with slow closing is that we kill the window right away > so it FEELS gone but it's not actually. You are sooo right. 1. Can't we make Firefox, if it's get closed (but the process is still running for the reasons of slow closing or installing the updates for the add-ons) go to tray as an icon, which will disappear only when the process firefox.exe is not running anymore? Hovering that icon should open a popup describing a reason why the firefox.exe process is still running (for example "Firefox is currently installing the updates for some of your extensions, please wait."). 2. Or even more advanced behavior: if during this time the user tries to run Firefox again - then the Firefox icon in the tray could hook this action and automatically show (without hovering the icon) a popup for the user saying that "This action has been queued: Firefox will open, after other actions get completed. Click to view the queue of actions." That would be extremely user-friendly behavior, I think. Should I open fill a bug for that? What do you think about these 2 ideas?
Closing this, as the main annoyance here was the add-ons updates, which have been removed in 4.0. I still agree that we should apply updates on shutdown instead of startup on platforms where we don't have an update service, and also recognize that there are still users that see slow shutdowns, see bug 239223.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
This is still an issue on the Nightly channel, for example.
(In reply to comment #6) > This is still an issue on the Nightly channel, for example. Do you have Tools -> Options -> Advanced -> Update -> "Automatically download and install the update" and "Automatically check for the updates to: Nightly" both checked?
Yes. There are two problems here. Under Windows 7, the updater asks for permission to run, and then you have to wait for the actual update. So, basically, the two bugs that this bug is marked as depends on.
You need to log in before you can comment on or make changes to this bug.