[Go Faster] Do we want system add-ons to update without restarting?

Richard Newman rnewman at mozilla.com
Sat Sep 26 22:55:28 UTC 2015

Do we have any measurements for the distribution of restart times? If 90%
of our users restart daily, 98% within a week, and we're happy getting 98%
penetration for an update in seven days, then great — let's not bother
notifying, and wait for organic restarts.

If we require users to restart in order to get fixes and improvements, and
if we prompt for upgrade, then we're forced to choose between update
fatigue or shipping less frequently. Even so, we'll get some number of
users (particularly on Mac, I suspect) not updating for extended periods of

(Yup, I still shake my head, restart Firefox, and jump it forward a couple
of major releases every time I use my partner's laptop.)

Putting on my devil's advocate hat: if we *don't* allow system add-ons some
way to upgrade without a restart, and if — as I've heard — the system
add-on approach doesn't really buy us faster turnarounds for chemspills, *is
it worth doing all of this work*?

If a user has to restart to get new software, what's the advantage versus
just pushing out a new build of Firefox and using our existing well-tested
delta-based updater with no nagging to restart?

On Fri, Sep 25, 2015 at 2:55 PM, Dave Townsend <dtownsend at mozilla.com>

> Support for updating system add-ons has landed in nightly (it isn't turned
> on yet but that is just a pref flip) but for the moment it still requires a
> restart to activate the new add-ons.
> We need to think about whether activating new versions without a runtime
> is something we want and if so whether we need some UI to allow the user to
> control when it happens. The problem is that at the moment the update
> process happens randomly during runtime. Imagine for a second that Firefox
> Hello is a system add-on and you're in the middle of a call to a friend
> when the update check finds an updated Firefox Hello. What happens next?
> For regular Firefox add-ons we just deactivate the old and activate the
> new. Presumably this would make the Firefox Hello call end abruptly, that's
> assuming it has been written well enough to do that when deactivated.
> Other choices include:
> 1. Leaving updates till after a restart, basically what a user is used to
> anyway.
> 2. Giving the user the choice of when to apply the updates, perhaps with
> some UI explaining what features might be interrupted. I'm not sure there
> are a lot of benefits to this above a restart.
> 3. Giving the add-on an API to delay updating. This makes the update code
> quite complicated and in a bad case might stop updates entirely.
> I'm leaning towards requiring a restart for now, it is the safest option
> and means we would need less QA around releasing new system add-ons since
> you wouldn't need to test updating with Firefox in various different states.
> _______________________________________________
> Gofaster mailing list
> Gofaster at mozilla.org
> https://mail.mozilla.org/listinfo/gofaster
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/gofaster/attachments/20150926/081d6611/attachment.html>

More information about the Gofaster mailing list