Mozilla upgrade experience
We currently have a couple of problems with the Firefox and Thunderbird upgrade experience, which users of Mozilla's update service don't experience (ie, everybody on Windows, Mac, or anyone using mozilla.org binaries on Linux).
1) A long standing issue we have is that upgrades totally break all currently running instances of Firefox or Thunderbird until they are restarted. This is made worse because we move the install location around between updates, but pulling the rug from underneath any running instance is probably never going to work reliably, even if the install location doesn't change.
Note, this isn't just an issue with Mozilla applications - we just notice it more because we update them a lot more frequently than anything else in the archive. As another example, there was a glade -> GtkBuilder transition a few cycles ago, where upgrades between distro-versions broke things such as the currently running instance of gnome-panel [2] due to the glade files being replaced with gtkbuilder ui files. I just wanted to point this out before people start blaming Firefox that this is really a problem with how our package manager works...
Upstream are currently planning work around silent updates, and they have a wiki page documenting how their update process will probably work [3]. We might be able to learn some things from this.
2) We have no way of warning people if any of their addons might stop working when we offer them an upgrade. People using upstream builds are notified before an upgrade if any of their ddons aren't compatible with the update, and if there are no addon updates available to fix this.
Do we want to provide such functionality, bearing in mind:
- We haven't had that many bug reports yet from users complaining of addons being incompatible after an upgrade, although there have been 1 or 2.
- As of the time of writing, 92% of addons on AMO are compatible with the current Firefox beta (due to be released on November 8th). However, approximately 75% of addons in use are not hosted on AMO [4].
- From Firefox 10 (Jan 31st, 2012), addons are going to default to being compatible, with some exceptions (addons with binary components) [4].
[1] - https:/
[2] - https:/
[3] - https:/
[4] - https:/
Blueprint information
- Status:
- Not started
- Approver:
- Sebastien Bacher
- Priority:
- Low
- Drafter:
- Chris Coulson
- Direction:
- Approved
- Assignee:
- Chris Coulson
- Definition:
- Approved
- Series goal:
- Accepted for quantal
- Implementation:
-
Deferred
- Milestone target:
-
ubuntu-12.10-beta-1
- Started by
- Completed by
Related branches
Related bugs
| Bug #422568: could not find glade file '/usr/share/gnome-panel/glade/clock.glade' | Invalid |
Whiteboard
didrocks, 2012-09-13: POSTPONED a remaining WI, let's tackle this next cycle
Previously: https:/
>"A long standing issue we have is that upgrades totally break all currently running instances of Firefox or Thunderbird until they are restarted."
- Yes, I have suffered this and lost work or some websites suddenly stop responding (once doing a financial transaction..). So after these experiences, I take precautions by explicitly checking the update list, close ff / tb or make sure i am not currently doing something important. But one can forget at times...
- A warning "before the update" would really be appreciated.
>"Note, this isn't just an issue with Mozilla applications - we just notice it more because we update them a lot more frequently than anything else in the archive. As another example, there was a glade -> GtkBuilder transition a few cycles ago, where upgrades between distro-versions broke things[...].
I just wanted to point this out before people start blaming Firefox that this is really a problem with how our package manager works..."
- Yes, it still has many limitations as you may see in this matrix:
http://
------------
Session notes:
* An application requires relaunching after updating
- Firefox 3.6 had this problem, recent versions do not
- Firefox may start having the problem again when it becomes multi-process
- Thunderbird may too
* A Firefox or Thunderbird add-on is incompatible with the newer version
- Add-ons are going to be marked compatible by default, starting Firefox 10
- Breakage should be caught during Aurora or Beta
- but many add-ons aren't hosted on a.m.o, so m.o can't bump their compatibility
* Something requires logging out before updating
- e.g. gnome-screensaver was not unlockable when it updated while open
- it had to be special-cased
- e.g. an update to Xorg crashes Xorg
- e.g. an update to pam had an ABI break that stopped cron, solved by a restart
- a flag wouldn't have helped here
- Is there a general solution to this?
- Have a class of updates that happen only when restarting or shutting down?
- Maintainers would need to remember to flag these updates anyway, and they might as well just fix the bugs.
* A Flash update is usually a security fix, so you need to relaunch the browser
Work from precise:
[chrisccoulson] Monitor whether marking Fx/Tb add-ons as compatible by default has worked out okay: DONE
[mpt] Write specific text for a security update that requires restarting Firefox <http://
[mpt] Discuss with Jono Xia a possible Test Pilot program on how quickly people relaunch after updating: DONE
[mpt] Arrange images+text for Test Pilot program and pass on to Jono Xia: DONE
Work Items
Work items:
Implement security-specific update notification in Firefox: POSTPONED
Implement update notification for Thunderbird, like "Your Rights" notification: POSTPONED
Add a restart-required banner to Firefox when any plug-in is upgraded: DONE
Dependency tree
* Blueprints in grey have been implemented.
