1061470 - [System Update] We should check if a new update is available before downloading

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[Julien Wajsberg [:julienw]]

STR:
1. have an update ready in the notification area
2. wait that another update is available (for nightlies, wait one day)
3. start and finish the update from the notification area 
4. after reboot, after some seconds and the update check, see that another update is ready


I think that at step 3 we should check if another update is ready before starting downloading the previous update. If another update is ready we should pick it automatically.


I think we use the same mechanism than Firefox but I don't see why Firefox couldn't use the same idea, so we can stay generic.

NI Dave Hylands about this idea. What do you think Dave?

Comment 1

[Dave Hylands [:dhylands]]

I think that this needs Robert Strong needs to buy in on.

I seem to recall bringing up something similar to this before.

See comments 12-17 on bug 831701

If we haven't started downloading, then I guess this might be considered differently.

I know with Aurora I find it really annoying that if I ignore the "There's a new version available" prompt for a couple days, that I always have to do a double update to get to the latest (first update is to finish applying the update I ignored) and then I have to update again to get the current update.

Comment 2

[Robert Strong (they/them - no direct email)]

For the haven't downloaded case where you require that the user opt-in I think it would be reasonable to check for a newer update via the B2G specific code during the opt-in process. Since Firefox doesn't require an opt-in there are other issues that would need to be addressed before doing something similar.

Comment 3

[Julien Wajsberg [:julienw]]

What do you call "opt-in" here exactly?

FTR I agree with Dave in comment 1: this is really annoying to double update (both in Firefox and Firefox OS).

Comment 4

[Robert Strong (they/them - no direct email)]

B2G requires that the user accepts the update before updating. That is why it is possible for B2G to implement this with B2G specific code as stated in comment #2.

Comment 5

[Julien Wajsberg [:julienw]]

Well:

* In Firefox, we also have the button in the About box.
* for unattended updates, the updates are unattended anyway so the newer update will be downloaded later anyway, so what's the point in downloading twice?

I don't get why this couldn't done in Firefox as well?

Comment 6

[Robert Strong (they/them - no direct email)]

Users that use Firefox for a short while during each cycle will end up in a continuous download loop and adding some form of protection to make damn sure and well that they don't end up in that state is non-trivial. Also, the main beneficiaries of this type of change are nightly and aurora users and without that protection I am not willing to have it on release. There is also tons of work that helps all users which is taking priority of such work for Firefox.

Comment 7

[Julien Wajsberg [:julienw]]

I quite disagree with you here.

Let's take the point of view of a release user. Here are the facts:
* we normally have one new release (so, one new download) every 6 weeks.
* If we have more than this, then it's probably a security update.

What can happen for a release user without the change we're talking about:
1. the user will download the new release entirely, then restart Firefox, and the release will be applied (nominal case)
2. the user will download the new release entirely but doesn't restart Firefox. The release is not applied for some time. If there is a new available download (security fix or new release), then it won't be downloaded until the user restarts Firefox.
3. the user will not download the new release entirely (as you said, he doesn't start Firefox often, or just starts it and then closes it when he doesn't need anymore). If there is a new available download (security fix or new release), then it won't be downloaded until the user keeps Firefox open long enough to get the download to complete, and _then_ keeps the new Firefox open long enough _again_ to get the yet new download to coplete.

I'll assert that cases 2 and 3 would not happen often for a release user, but when they happen we definitely want to pick up the new download. 

That said, for the B2G case, I'd be happy enough if we'd do this check only when _starting_ the download. I'd be sad if we'd do the fix only for B2G because I see the improvements for Firefox too.

Comment 8

[Robert Strong (they/them - no direct email)]

(In reply to Julien Wajsberg [:julienw] from comment #7)
> I quite disagree with you here.
> 
> Let's take the point of view of a release user. Here are the facts:
> * we normally have one new release (so, one new download) every 6 weeks.
> * If we have more than this, then it's probably a security update.
> 
> What can happen for a release user without the change we're talking about:
> 1. the user will download the new release entirely, then restart Firefox,
> and the release will be applied (nominal case)
> 2. the user will download the new release entirely but doesn't restart
> Firefox. The release is not applied for some time. If there is a new
> available download (security fix or new release), then it won't be
> downloaded until the user restarts Firefox.
> 3. the user will not download the new release entirely (as you said, he
> doesn't start Firefox often, or just starts it and then closes it when he
> doesn't need anymore). If there is a new available download (security fix or
> new release), then it won't be downloaded until the user keeps Firefox open
> long enough to get the download to complete, and _then_ keeps the new
> Firefox open long enough _again_ to get the yet new download to coplete.
> 
> I'll assert that cases 2 and 3 would not happen often for a release user,
> but when they happen we definitely want to pick up the new download. 
Agreed for the most part. My point is that the number of users that don't restart in a week is extremely minuscule per a couple of previous studies (iirc over 99% restart week), these users will pick up the latest version at some point, and the users I am concerned about could end up in a state where they don't pick up a newer version.

As I also said, "There is also tons of work that helps all users which is taking priority of such work for Firefox." I am not saying we shouldn't do this. I am saying that doing it partially without taking into account the issue I stated could badly affect Firefox users.

> That said, for the B2G case, I'd be happy enough if we'd do this check only
> when _starting_ the download. I'd be sad if we'd do the fix only for B2G
> because I see the improvements for Firefox too.
My point is that B2G could implement this now whereas we don't have resources to do this in app update atm. Also, the B2G specific code will likely need to be updated anyways for this change.

Comment 9

[Julien Wajsberg [:julienw]]

Ok thanks for your advice, let's do this in B2G then.

Comment 10

[BMO Automation]

Firefox OS is not being worked on