998962 - Allow www.mozilla.org pages (whitelisted) to know if an Fx update is pending or available

Status: NEW

(Firefox :: General, defect)

Description

[Holly Habstritt Gaal [:Habber]]

Attachment: About Firefox window

Problem:
On Mozilla.org we are unable to tell if users have a silent update waiting for them. On 'www.mozilla.org/firefox/new/' (our primary Firefox browser download page) and other pages where download buttons exist across Mozilla.org we find that current Firefox users are installing a fresh copy of Firefox. One reason for this is that they do not understand that a silent update has occurred or how they work. 



Details:
Currently, we can tell if a user is "Up to date" or "Not up to date" and provide appropriate conditional messaging and next steps to the user in the web page based on this. However, for "Not up to date" users we still show a download button as a best case scenario. If the web can tell the status of a silent update, we can provide smarter information to the user and avoid unnecessary fresh downloads.

A related need to keep in mind is the ability to trigger a silent update from the web if it has stopped due to connectivity issues.  



Solution:
Allow the web to know the status of a silent update. If this status is known, smarter conditional messaging will be provided on the corresponding web page. The functionality that we would like in the web page is similar to the button in the About Firefox window. See attached screenshot.

Comment 1

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

I believe that app update already has the api's for this and what will be needed is a way for Firefox to query this information and provide it to mozilla.org, etc. when visiting the web site so moving this bug to Firefox where the actual work will be performed.

Comment 2

[Justin Dolske [:Dolske]]

This would be WONTFIX as filed -- exposing pending-update info to any arbitrary web site isn't something we'd do. But it would be reasonable to whitelist mozilla.org/mozilla.com as a special case.

Is there reason to think this is a common problem?

Comment 3

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

Good question and I'll be back with an answer tonight.

Comment 4

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

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #3)
> Good question and I'll be back with an answer tonight.
Actually, I won't be able to come up with a decent answer for this though I can tell when people are installing on top of or close to the same version. We could add metrics to the stub installer to get a better answer to this question though.

Comment 5

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

A couple of notes from the stub ping data from the last 6 months:
approximately 25% of all installs are installing on top of an existing install.
approximately 32% of these installs are installing on top of the exact same version.

Comment 6

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

This is really about whether there is an update pending and not just silent updates which was a project that removed the UAC dialog so fixing summary

Comment 7

[Holly Habstritt Gaal [:Habber]]

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #5)
> A couple of notes from the stub ping data from the last 6 months:
> approximately 25% of all installs are installing on top of an existing
> install.
> approximately 32% of these installs are installing on top of the exact same
> version.

Justin, you are correct that this would be exposed to Mozilla.org whitelisted pages only. 

Thanks for the data, Robert. That's a significant number happening over existing installs. We found a similar outcome in a survey placed on the /firstrun page, though some of these users do want a fresh install to fix performance issues. https://bugzilla.mozilla.org/show_bug.cgi?id=932572 

Do you have location information for the stub ping data?

Comment 8

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

There is GEO data for the stub ping data.

Comment 9

[Verdi [:verdi] Best to slack me]

We could use this info on sumo too. We get a significant amount of people looking for information about updating and it would be great (especially where bandwith is limited or connectivity is spotty) to let them know when they can restart instead of downloading another copy.

Comment 10

[Jennifer Bertsch [:jbertsch]]

Cmore and Verdi:  Is this on the growth team list?

Comment 11

[Holly Habstritt Gaal [:Habber]]

Attachment: sync_signedin.png

We've discovered another case where this functionality on white listed Mozilla.org pages would be useful. Users on Fx 28 and older can only use the old version of Sync. On pages where it makes sense to do so, we would like to prompt users to update their browser so they can take advantage of the newer version of Sync. 

The upcoming Sync marketing page could benefit. As it stands now, we can ask these users to update their Firefox, but send them to the SUMO page which explains how to update. A better user experience would trigger the update from this page instead of taking them away from the page to read instructions.

Comment 12

[Chris More [:cmore]]

(In reply to Jennifer Bertsch [:jbertsch] from comment #10)
> Cmore and Verdi:  Is this on the growth team list?

This sounds like a project on the Fx Growth team back log:

"Project UpdateFox	Test opening a chrome window on mozilla.org to force an update for Fx users"

Basically, if an update is pending and they visit the download page, pop open the chrome about page where they can click the "restart to update" button.

Though, it may be a better UX to have the whitelisted mozilla.org websites to trigger the same action that the "restart to update" button instead of opening the chrome dialog box.

Holly: Thoughts on a chrome dialog box vs making the download button (replaced with Update Firefox or something similar) initiate the restart?

Comment 13

[Holly Habstritt Gaal [:Habber]]

I think there are 2 parts to consider. 

1. Allowing a whitelisted page to know the status of a silent update. If we know an update is in progress or complete, we can offer the appropriate conditional message and/or next action for this user to take.

2. If we have this info, what can we do with it? 



(details about options in comment #12)
2a. About:Firefox modal - 
A benefit of this is that if the update is either in progress or complete and we want to offer one action that covers both, we could do the following... Display a "Your browser is already being updated." message on /new and offer a "check status" button on that opens the about:firefox modal. The modal itself would handle telling the user's the update status and offer the restart button. The web page would only have to provide messaging and CTA and leave the rest to the about:firefox modal.

2b. In-page status + restart button - 
However, it would be more informative and nicer UX to not hide this behind a "check status" type of CTA. If we know that a silent update is complete, we could tell the user directly on this page and offer a restart button directly in the page. We would want to prompt them with an "are you sure" type of dialog since it may not be expected that you would have this ability from a web page. In visual design, the more we can make the message appear as though it is coming from Firefox, the better. If we know that an update is in-progress it would be great if we could show a progress counter with an inactive restart button until update is complete. (download fresh copy link could still be available here as well)

Thoughts?