Closed Bug 952549 Opened 11 years ago Closed 10 years ago

Update ESR versions in the Firefox details

Categories

(www.mozilla.org :: Bedrock, defect)

Product:
www.mozilla.org
Component:
Bedrock
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1022900

People

(Reporter: kohei, Assigned: kohei)

References

Details

(Whiteboard: [kb=1221733] )

Attachments

(3 files)

Pull Request on GitHub
44 bytes, text/x-github-pull-request
Details | Review
Screenshot of Update Bar
221.92 KB, image/png
Details
pull request to backout the previous change
44 bytes, text/x-github-pull-request
Details | Review
Attached file Pull Request on GitHub —
+++ This bug was initially created as a clone of Bug #935719 +++ The firefox_details.esr_major_versions array is used for version checks. It should be up-to-date. The pages under /firefox/ have the array as <html data-esr-versions="[10, 17, 24]">
Whiteboard: [kb=1221733]
Lukas- Do we want to do this? Thanks, Jen
Flags: needinfo?(lsblakk)
I'm not familiar with what this does. It looks like it's supposed to only have the most up to date version in it, which it does with [24] - who authored this and can say more about how it's used? Mostly I want to make sure we're not in any way pointing people to dead-end 10 or 17 release binaries.
Flags: needinfo?(lsblakk)
This esr_major_versions array has been used for users' version check on http://www.mozilla.org/firefox/fx/ and http://www.mozilla.org/en-US/firefox/new/ We have to fix this because Firefox 10 or 17 users visiting /firefox/new/ currently see an inappropriate message: "Congrats! You’re using the latest version of Firefox." The array will also be used for a version check in Tabzilla (Bug 935719).
This would tell people on 10 or 17 that they nee to update. Is that desired effect? It may be, since it IS out of date, but on the other hand, there isn't much they can do about it.
Jen or Holly: Any ideas here? Telling a 10 or 17 ESR user that they should upgrade it likely pointless as their Fx is managed by their corporate IT and if they download a normal release they'll likely not be allowed to install it anyway. We could potentially have special ESR messaging but we don't currently.
Flags: needinfo?(jbertsch)
Flags: needinfo?(hhabstritt.bugzilla)
Yes, ESR 10 and 17 users will also get an update advisory with this change. I think it's better than the current wrong "up-to-date" message. The advisory links to https://support.mozilla.org/kb/update-firefox-latest-version so we could add some info for ESR users on this article, just say "Ask your system administrator to update."
I agree, we shouldn't worry about ESR users who can't update getting this message, they will likely contact their helpdesk to ask for help in updating and the request volume may prompt faster deployment of a modern ESR version. Also, there are most likely lots of end-users who do have admin rights who installed the ESR as well who should be promoted to update (even though we don't support End user use of ESR)
Could I please see a screenshot of what the page looks like when this happens? That will help me to understand exactly what we should change in the messaging and if we should update any links for ESR users. My initial comments are in line with Kohei in that we shouldn't be showing them the wrong up-to-date message. (In reply to Kohei Yoshino [:kohei] from comment #6) > Yes, ESR 10 and 17 users will also get an update advisory with this change. > I think it's better than the current wrong "up-to-date" message. The > advisory links to > https://support.mozilla.org/kb/update-firefox-latest-version so we could add > some info for ESR users on this article, just say "Ask your system > administrator to update."
Flags: needinfo?(hhabstritt.bugzilla)
Habber: Here's a screenshot of the Update Bar that has been implemented in Bug 935719. A screenshot of /firefox/new/ is Attachment 793040 [details] attached in Bug 883800.
Thanks Kohei! We should offer a unique message for not up-to-date ESR users. Here is my recommendation: "Your Firefox is not up-to-date. Ask your help desk or system administrator to [update]." The word "update" in that sentence could link to the sumo article about updating (https://support.mozilla.org/en-US/kb/update-firefox-latest-version). Is the article still helpful even though the user is not able to perform the update without help from a sys admin? I think it is still helpful to link to so that we can catch as many users as we can from installing a fresh copy. For the copy in the banner (http://cl.ly/image/3I300U1T3L3m) I'd recommend changing "Later" to "Update later."
The issue with that messaging is that we have no way to tell via the UA if users on Firefox 10 or 17 are ESR or are regular users. Since all versions of firefox have a long tail of users that don't update, we can safely assume that many of the users on 10 or 17 are regular users, not ESR.
I was thinking the same thing as Tyler. The messaging itself looks good, but currently we have no reliable way to detect ESR users. Here's my idea: In the short term: Use the same messaging for all users, and add an additional info for ESR users to the SUMO article. In the long term: Add the build ID of each Firefox build (e.g. https://wiki.mozilla.org/Releases/Firefox_26/Test_Plan#Build_Info_10) to the Firefox details database, and compare browser's navigator.buildID DOM property against that database to detect the release channel.
Note: there's some discussion on the navigator.buildID property because it can be used for user fingerprinting that leads a privacy issue. That's why the UA string now contains a limited info. There's a request to reveal the build ID only to select sites: Bug 583181. Even if this is implemented, www.mozilla.org can be whilelisted.
Ahh, Firefox 24.0 and Firefox 24.0 ESR share the same build ID: https://wiki.mozilla.org/Releases/Firefox_24/Test_Plan#Build_Info https://wiki.mozilla.org/Releases/Firefox_24_ESR/Test_Plan#Firefox_24_ESR We can still detect Firefox 24.x.x ESR though.
I misunderstood and thought we could detect ESR users. I agree with the next steps Kohei listed here. Once there is a way to detect ESR users on /new before they land on a SUMO page, I'm happy to help. (In reply to Kohei Yoshino [:kohei] from comment #12) > I was thinking the same thing as Tyler. The messaging itself looks good, but > currently we have no reliable way to detect ESR users. Here's my idea: > > In the short term: Use the same messaging for all users, and add an > additional info for ESR users to the SUMO article. > > In the long term: Add the build ID of each Firefox build (e.g. > https://wiki.mozilla.org/Releases/Firefox_26/Test_Plan#Build_Info_10) to the > Firefox details database, and compare browser's navigator.buildID DOM > property against that database to detect the release channel.
:Habber So here's the deal. Kohei is right that we can't for 100% sure know that a user of 10 or 17 is an ESR user. We're pretty sure they are though because auto-updates should have moved everyone on the normal builds of those versions to the latest. In our Vidyo discussion we thought perhaps something like your suggested line from comment #10 would be good along with something to the effect of "If you're in a corporate environment..." as a conditional. We do want to offer them an upgrade, but also want to try to prevent them from needlessly downloading a build they're not allowed to install.
Flags: needinfo?(hhabstritt.bugzilla)
Flags: needinfo?(jbertsch)
Note that the Update Bar (Attachment 8356201 [details]) has a limited space for a longer messaging. We could probably keep the current string "Looks like you’re using an older version of Firefox. Update to stay fast and safe." and update the linked SUMO article to add some ESR-specific info.
Blocks: 939470
* For users visiting any non /new page that have builds 10 and 17 (that are out of date ESRs) we show a link in the update bar (http://cl.ly/image/0f3Z3T3Z0L2G) that directs the user to a SUMO article to help installing. "Looks like you're using an older version of Firefox. [ Get a new version now. ]" Copy in brackets links to SUMO link. (copy is FPO) * For users visiting /new that have builds 10 and 17 (that are out of date ESRs) we will show them the following line of copy in the conditional copy area at the top of the page: "Looks like you're using an older version of Firefox. [ Need help installing? ]" Copy in brackets links to SUMO link. (copy is FPO) Michael, do we have any SUMO documentation that assists ESR users in installing Firefox? These users (if in a corporate environment) may need to contact their IT dept to install).
Flags: needinfo?(mverdi)
So I was wrong about Fx 24 ESR builds reporting the minor version in the User-Agent string. This is the UA string for Fx 24.2: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Firefox/24.0 That's exactly the same as non ESR Fx 24. So perhaps we should file a bug like Kohei suggested for a read-only property on white-listed domains (e.g. mozilla.org) that would allow us to recognize ESR builds? This doesn't change how we're planning to handle 10 and 17 ESRs, but it does mean that the situation won't improve with 24 as I suggested it would earlier.
> That's exactly the same as non ESR Fx 24. Yes, Bug 870540 did it. Firefox could expose such a property on white-listed domains: navigator.mozAppDetails = { 'channel': 'nightly', 'aurora', 'beta', 'release' or 'esr', 'version': a full version like '24.2.0', 'buildID': currently exposed as navigator.buildID (Bug 583181 will hide it) }
Filed Bug 952549 for navigator.mozAppDetails. It won't block this change as :pmac said.
See Also: → 966030
(In reply to Holly Habstritt [:Habber] from comment #18) > Michael, do we have any SUMO documentation that assists ESR users in > installing Firefox? These users (if in a corporate environment) may need to > contact their IT dept to install). Our policy is not to create special ESR documentation. The idea being that the official support for ESR is done by their IT departments and the IT departments can get support on the ESR mailing list. Of course the regular support documentation will always be up-to-date for, at least, the current ESR version. Current sumo documents support back to Firefox 17. I think many people using Firefox 10 and 17: 1. Are not on ESR 2. Are on ESR but not enterprise users 3. Are stuck on these versions for various reasons (updates turned off, update mechanism failed, OS doesn't support new version). FWIW, the latest traffic on sumo says that about 33% of Firefox 10 users are definitely using an ESR build and only .05% of Fx 17 are definitely on an ESR build. My thought is that we should treat these people like any other out-of-date Firefox user. This would point them to the update article which tells people to download from https://www.mozilla.org/firefox/all/ if the update fails. 85% of the people who read that article consistently say it was helpful.
Flags: needinfo?(mverdi)
So we could consider only Firefox 24 as a special case? Then my pull request https://github.com/mozilla/bedrock/pull/1549 will do the right thing. As :verdi said, Firefox 10/17 users might be non-ESR users. And as I mentioned in yesterday's meeting, even non-ESR builds could be used and managed by organizations, though Mozilla encourage them to use ESR. So the situation is still complicated...
How can we proceed further here?
Flags: needinfo?
Firefox 28 is just out. I believe it's okay to treat 10 and 17 as outdated versions regardless of the channels, since those are totally out-of-date. I'd like to reopen my pull request https://github.com/mozilla/bedrock/pull/1549 and go ahead with Bug 935719. Thoughts?
Yes, all users on 10 and 17 are out of date, regardless if they are ESR or not.
Flags: needinfo?
Reopened my PR #1549 to mark Firefox 10 and 17 obsolete. Firefox 24 is still treated as up-to-date. We could revisit the detection and messaging for people using older 24.x in another bug.
Filed Bug 988725 to override the UA string in the next ESR.
See Also: 966030 → 988725
Commits pushed to master at https://github.com/mozilla/bedrock https://github.com/mozilla/bedrock/commit/a0b8b26afb4fca1c09ec6037499c96fed7246096 Fix Bug 952549 - Update ESR versions in the Firefox details https://github.com/mozilla/bedrock/commit/ee5a9a6fde0a6e7401069caee45e334eb44cc9a7 Merge pull request #1549 from kyoshino/update-esr-versions Fix Bug 952549 - Update ESR versions in the Firefox details
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Also discussed in this bug is how to accommodate ESR users who arrive on /new. Updated today, the following SUMO article will display conditional messaging to help ESR users on 10, 17, and 24 for en-us - https://support.mozilla.org/kb/update-firefox-latest-version /new displays conditional messaging to tell the user about their browser status. For not up-to-date users arriving on /new, we will do the following: 1. Not up-to-date users NOT on 10, 17, 24 (this is the current behavior and messaging): "Looks like you're using an older version of Firefox. [ Update to stay fast and safe. ]" 2. Not up-to-date users on 10, 17, 24 (new copy for these users): "Looks like you're using an older version of Firefox. [ Need help? ]" Link in brackets [ ] points to https://support.mozilla.org/kb/update-firefox-latest-version Do we have a string from elsewhere that we can use for "Need help?" or does this need to be translated?
Flags: needinfo?(hhabstritt.bugzilla)
So basically I have to revert this change to keep treating 10 and 17 (and 24) users as exceptions. The messaging looks good -- we already have the string "Need help?" on /firefox/new/ so it won't require an additional l10n.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
But there's still no simple way to distinguish between 24 ESR and non-ESR users. Should we try using navigator.buildID until Bug 988725 is implemented?
24 ESR build IDs can be found at https://wiki.mozilla.org/Releases/Firefox_24_ESR/Test_Plan
ESR versions have been updated in Bug 1022900.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: