Closed Bug 772637 Opened 12 years ago Closed 7 years ago

Alternate update checks to backstop normal ones

Categories

(Toolkit :: Application Update, defect)

Product:
Toolkit
Component:
Application Update
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: jesup, Unassigned)

Details

Default update checks miss some users:
* ones who start FF, check stuff, and exit
* ones who ignore update messages thinking they're spam
* ones who turn off their modems when they're not actively online
* dialup users (esp. third-world)
* others?

  Many users have been taught "don't accept anything that pops up!" by their children/etc
etc (see discussion in forum)

Some backstop ideas to reduce changes that users never or rarely see update options:

We should check sooner (shortly/right after startup, IF:
* If we haven't completed an update check successfully in X days
* If we haven't been started in Y days (Y >> X)
etc.

Perhaps also alternate notices if the version is more out-of-date.  The normal update messages are also unthreatening to the point where users may blow them off.  There's a balance there between "update or die!" and "hey, there's this update out there, you might want to think about it".  :-)
(In reply to Randell Jesup [:jesup] from comment #0)
> Default update checks miss some users:
> * ones who start FF, check stuff, and exit
> * ones who ignore update messages thinking they're spam
> * ones who turn off their modems when they're not actively online
> * dialup users (esp. third-world)
> * others?
> 
>   Many users have been taught "don't accept anything that pops up!" by their
> children/etc
> etc (see discussion in forum)
By defaut, we only prompt when there are incompatible add-ons or the user explicitly changes preferences to require prompting. We can require that the user sees a notification but we typically don't and if we decide to we should just say "don't do that" to fix this case. For the case of incompatible add-ons the effort should be around making them compatible. We could also change the default Firefox preference to not check for incompatible add-ons to work around this but drivers don't want to do this (I personally agree with this decision and I am just pointing it out).

> Some backstop ideas to reduce changes that users never or rarely see update
> options:
> 
> We should check sooner (shortly/right after startup, IF:
> * If we haven't completed an update check successfully in X days
We check when the last check is 24 hours or more prior and then check within 10 minutes after startup.

If there is a download in progress we immediately resume the download.

> * If we haven't been started in Y days (Y >> X)
> etc.
If it is more than 24 hours since the last check then we check within 10 minutes after startup.

> 
> Perhaps also alternate notices if the version is more out-of-date.  The
> normal update messages are also unthreatening to the point where users may
> blow them off.  There's a balance there between "update or die!" and "hey,
> there's this update out there, you might want to think about it".  :-)
We don't show notices unless have been moving towards not notifying with a default configuration through efforts around add-ons being made compatible.

Also, I'm not a big fan of bugs that aren't directly actionable and with the above in mind this bug really needs to be clarified.
It's possible that waiting 10 minutes after startup is too long for short-lived sessions. Do we have any data on session length ?
There was a testpilot study from a while ago (don't have the link or data anymore) that iirc inferred 10 minutes was plenty of time though I am sure there will be some edgecases where the user doesn't stay running long enough for x amount of days.

Also, this can be tuned by each application
http://mxr.mozilla.org/mozilla-central/source/browser/app/profile/firefox.js#71

How long to wait after startup for the first firing of the timer can be controlled by adding the following pref as well.
app.update.timerFirstInterval
I was asked to file this by johnath

In some cases it may be too short, which was a big thing this bug was about (check immediately if we've been "a long time" without an update (check) as a backstop).

Some people start up, check, and exit.  It's a work flow habit for some.  Others as mentioned reflexively close any windows that pop up telling them to do something (out of fear, not totally unreasonable - they can't tell what's safe or not).
(In reply to Randell Jesup [:jesup] from comment #4)
> I was asked to file this by johnath
> 
> In some cases it may be too short, which was a big thing this bug was about
> (check immediately if we've been "a long time" without an update (check) as
> a backstop).
> Some people start up, check, and exit.  It's a work flow habit for some. 
For that case the prefs mentioned in comment #3 could be adjusted and be an adequate solution though it would be best to have a study to see if this is necessary.
http://mxr.mozilla.org/mozilla-central/source/browser/app/profile/firefox.js

For one-off tuning Firefox has code that runs on every startup unlike app update and this code could make the decision without requiring the app update code to load which would be a perf hit.

In both of the above cases this would be tuned for Firefox users and fixed in the Firefox product.

> Others as mentioned reflexively close any windows that pop up telling them
> to do something (out of fear, not totally unreasonable - they can't tell
> what's safe or not).
I think the best way to address this is by not displaying the ui as stated in comment #1 and additional efforts should be around making more add-ons compatible.
Yeah, I asked Randall to file it after it came up in a discussion thread in the (nearly abandoned) intranet forums.

Specifically I was focused on update timing, and the concern that users whose browser workflow is launch, check hotmail, close. I don't know how many users that represents, and doubt we could get very good numbers from them (they won't be test piloters, I doubt they'll have telemetry turned on) but the suggestion of a quicker update check for those users sounded like a sensible tweak.

Having seen Robert's answer that we do our check 10 minutes in (for some reason I thought it was 30) is reassuring. I imagine we'd pick up a marginal win with a little bit of extra cleverness (if it's been more than a week, check 30 seconds after startup and deal with the occasional perf hit). Without numbers it's hard to predict how much it matters - probably more than zero, probably not a ton.

The other discussion in the bug about dialogs and user behaviours I'm less worried about. Most users don't see them.
With silent updates this is less of an issue - though do silent updates apply to nightly/beta/aurora builds?  From what I've seen, no, but I haven't looked that closely.  Admittedly those people are more likely to allow an update (at some point).  Some of the bugs that point to very old Firefoxes crashing with very new glibc's had a preponderance of aurora/beta versions over release, for example.

The user behavior of "close the window of ANYTHING that pops up" may be more common than people realize.  Lots of people are horribly afraid (not entirely without reason) that something they click on will hack their computer, especially popups telling them to upgrade (a major social-engineering thing in driving people to 'bad' sites and to install upgrades, virus scans, etc - many users can't tell the difference and their children/friends/etc have told them "close anything that pops up that you didn't ask for").

Maybe take some crash reports with old revs, contact the users, and ask them to run some diagnostics or export some logs, etc, and try to see if there are any patterns to the "old versions still in use".
(In reply to Johnathan Nightingale [:johnath] from comment #6)
> Yeah, I asked Randall to file it after it came up in a discussion thread in
> the (nearly abandoned) intranet forums.
> 
> Specifically I was focused on update timing, and the concern that users
> whose browser workflow is launch, check hotmail, close. I don't know how
> many users that represents, and doubt we could get very good numbers from
> them (they won't be test piloters, I doubt they'll have telemetry turned on)
> but the suggestion of a quicker update check for those users sounded like a
> sensible tweak.
> 
> Having seen Robert's answer that we do our check 10 minutes in (for some
> reason I thought it was 30) is reassuring. I imagine we'd pick up a marginal
> win with a little bit of extra cleverness (if it's been more than a week,
> check 30 seconds after startup and deal with the occasional perf hit).
> Without numbers it's hard to predict how much it matters - probably more
> than zero, probably not a ton.
One simple way to mitigate this would be to change the Firefox preferences for when the timers fire.

app.update.timerMinimumDelay is currently 120 which means we wait a minimum of 2 minutes between notifying consumers of the timer manager. We could go with 60 seconds.

app.update.timerFirstInterval is currently undefined which means it waits 120 seconds before notifying any consumers of the timer manager. We could change it to 60 seconds.

With the above changes an update check should happen anywhere from 1 minute to 5 minutes after startup.

> The other discussion in the bug about dialogs and user behaviours I'm less
> worried about. Most users don't see them.
Agreed though it is important to note that the only reason a user should see a prompt is if they have add-ons that are incompatible with the update or they changed the preferences so they are prompted.
(In reply to Randell Jesup [:jesup] from comment #7)
> With silent updates this is less of an issue - though do silent updates
> apply to nightly/beta/aurora builds?  

Silent updates do apply to all channels. On Nightly we prompt more frequently (this is a deliberate action) as there are more builds. So, you actually see increasing prompting to restart. However, on Windows you will not have to click on the UA, there is no what's new page each time you restart, the update will be applied in the background (decreasing restart time), and add-ons still default-to-compatible.
(In reply to Johnathan Nightingale [:johnath] from comment #6)
> The other discussion in the bug about dialogs and user behaviours I'm less
> worried about. Most users don't see them.

Do we have telemetry data indicating what percentage of users does see them?
(In reply to Henri Sivonen (:hsivonen) from comment #10)
> (In reply to Johnathan Nightingale [:johnath] from comment #6)
> > The other discussion in the bug about dialogs and user behaviours I'm less
> > worried about. Most users don't see them.
> 
> Do we have telemetry data indicating what percentage of users does see them?

I think we're starting to get off topic for this bug, but we re-calibrated the update prompt to happen 24 hours (I believe) after an update is available instead of the original 4h or 12h or something because telemetry data told us that more than 99% of users were restarting at least once a day anyhow (and hence didn't need prompting).
With all of the changes since this bug was filed I don't think this bug provides value anymore. We seldom show UI and the timer prefs have been shortened so update checks can happen as soon as 30 seconds after start iirc.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.