814055 - [Updates] don't delay the updates notification if the user forced the check

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::System, defect)

Description

[Julien Wajsberg [:julienw]]

Right now we delay the updates notification (30 seconds IIRC) so that we can group the notifications.

But we should not delay the notification if this is a forced check (which means the user pushed the "check updates now" button in the settings app).

Comment 1

[Josh Carpenter [:jcarpenter]]

Great point, Julien. Totally agree.

Comment 2

[Julien Wajsberg [:julienw]]

That was really Etienne's idea but he likes me to open his bugs ;)

Comment 3

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

gaia triage : - ; users shouldn't need to update so often.

Comment 4

[Josh Carpenter [:jcarpenter]]

(In reply to Julien Wajsberg [:julienw] from comment #0)
> Right now we delay the updates notification (30 seconds IIRC) so that we can
> group the notifications.
> 
> But we should not delay the notification if this is a forced check (which
> means the user pushed the "check updates now" button in the settings app).

Actually now I give this some more thought, we delay showing a notification so that the remote sources we poll for available updates have time to respond back. Wouldn't we still need this delay, for the same reason, even in manual checks? In the interim while the user is waiting, could we display a spinner GIF next to the manual check button in Settings?

Comment 5

[Julien Wajsberg [:julienw]]

Actually, I don't remember why we have to delay the notification at all, because we can know (with the ugly setting change) when the update is complete and then show the notification immediately.

Etienne, could you help us here ?

Comment 6

[Etienne Segonzac (:etienne)]

(In reply to Julien Wajsberg [:julienw] from comment #5)
> Actually, I don't remember why we have to delay the notification at all,
> because we can know (with the ugly setting change) when the update is
> complete and then show the notification immediately.
> 
> Etienne, could you help us here ?

We're getting various download available events in a row (that's what triggers the notifications), so we're waiting a bit to make sure we're showing the notification only once with the total update count.

Keep in mind that the force-check is not the only path to the update available notifications.

Comment 7

[Julien Wajsberg [:julienw]]

etienne> yeah but we still should get the "gecko/apps.updateStatus" settings change with the "check-complete" value, and then we can display the notification asap.

The only problem with this approach is if an update check is very long (like the server is down and the request times out), so we may have to use both the timeout and the settings change. But then it would work for both possibilities.

Comment 8

[Etienne Segonzac (:etienne)]

(In reply to Julien Wajsberg [:julienw] from comment #7)
> etienne> yeah but we still should get the "gecko/apps.updateStatus" settings
> change with the "check-complete" value, and then we can display the
> notification asap.

And I have nothing against that!
Just answering the previous question :)

Comment 9

[Julien Wajsberg [:julienw]]

ok, so that might be a plan if we decide to fix this bug (that is BB-, so maybe later in january ;) )

Comment 11

[BMO Automation]

Firefox OS is not being worked on