Last Comment Bug 1125166 - Some mozilla.org-sites consider 31.4ESR to be out of date
: Some mozilla.org-sites consider 31.4ESR to be out of date
Status: RESOLVED FIXED
[kb=1640636]
:
Product: Websites
Classification: Other
Component: Tabzilla (show other bugs)
: Production
: All All
-- normal (vote)
: ---
Assigned To: Kohei Yoshino [:kohei]
:
:
Mentors:
https://support.mozilla.org/en-US/
Depends on:
Blocks: 935719 1128919
  Show dependency treegraph
 
Reported: 2015-01-23 07:53 PST by Elbart
Modified: 2015-02-03 04:41 PST (History)
4 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
31esr_out_of_date.png (139.73 KB, image/png)
2015-01-23 07:53 PST, Elbart
no flags Details
pull request (44 bytes, text/x-github-pull-request)
2015-01-23 14:59 PST, Kohei Yoshino [:kohei]
no flags Details | Review | Splinter Review

Description User image Elbart 2015-01-23 07:53:55 PST
Created attachment 8553759 [details]
31esr_out_of_date.png

Visiting mozilla.org or support.mozilla.org shows a notification-bar with the message that the used Firefox-version was out of date.

But visiting https://www.mozilla.org/en-US/firefox/new/ shows "Congrats! You’re using the latest version of Firefox."

Thread on the enterprise-ML:
https://mail.mozilla.org/private/enterprise/2015-January/005343.html
Comment 1 User image Kohei Yoshino [:kohei] 2015-01-23 10:00:06 PST
That's the Update Bar I have implemented on Tabzilla :( Will figure out why.
Comment 2 User image Kohei Yoshino [:kohei] 2015-01-23 10:21:20 PST
Looks like we have intentionally dropped the ESR exception in Bug 935719. We should probably revert it until ESR 31 goes EOL this summer.
Comment 3 User image Kohei Yoshino [:kohei] 2015-01-23 10:31:20 PST
This was my initial proposal for Bug 935719:
https://github.com/kyoshino/bedrock/compare/tabzilla-updatebar
Comment 4 User image Alex Gibson [:agibson] 2015-01-23 10:57:11 PST
After much discussion amongst the mozilla.org team, we recentlym ade the decision not to treat ESR builds as up-to-date (see Bug 1122154)

This has not made it to production yet, but has been merged - should probably also be taken into account here.
Comment 5 User image Kohei Yoshino [:kohei] 2015-01-23 12:29:48 PST
Hm, yeah. This bug (Tabzilla) and Bug 939470 (/firefox/new/) have the same issue.

So... I'd like to implement a tentative solution using navigator.buildID as I proposed before. If the property value is "20140716183446" the browser is outdated non-ESR 31.0, otherwise the browser is ESR 31.0.x. 

https://wiki.mozilla.org/Releases/Firefox_31/Test_Plan#Release_Candidate_2
https://wiki.mozilla.org/Releases/Firefox_31_ESR/Test_Plan#Firefox_31_ESR

After ESR 31 goes EOL, we can remove the hardcoded workaround and instead rely on the mozUITour API.

Thoughts?
Comment 6 User image Alex Gibson [:agibson] 2015-01-23 12:32:54 PST
Thanks Kohei - as mentioned above, after a long discussion we have decided not to treat ESR users as up to date. This has been discussed at length quite a few times amoung the group, so for now this is where we are settled. If that changes in the future we can be sure to revisit these options.
Comment 7 User image Kohei Yoshino [:kohei] 2015-01-23 13:08:02 PST
Then this bug and Bug 939470 would be WONTFIX? ESR users will continue to see the incorrect message and we'll probably get the same bug reports again and again :(
Comment 8 User image Alex Gibson [:agibson] 2015-01-23 13:13:54 PST
Bug 939470 seems a little different, as the minor version differences are not restricted to ESR users. As far as ESR builds go, yes we currently do not plan to treat them as up to date. The reasons for this have been discussed at length as far as I understand.
Comment 9 User image Jon Petto [:jpetto] 2015-01-23 13:32:02 PST
tl;dr - We would rather incorrectly tell ESR users that they are out of date than incorrectly tell release users they are up to date.

The goal of the recent ESR detection changes is to not let a release channel user who happens to be on a version that matches an ESR version think they are up to date. In production currently, if a release channel user on version 31.x visits any page using isFirefoxUpToDate version detection, they are assumed to be up to date. This is incorrect behavior for the majority of our users (release channel).

At our next production push, the change in PR 2673 (https://github.com/mozilla/bedrock/pull/2673) will go live and correct the situation described above.

The down side to this change is that ESR users will likely see messaging telling them they are not up to date. If we can leverage navigator.buildID to more intelligently detect ESR users without affecting release channel user version detection, I think that would be fine.

When *all* ESR users are on 35+ (with access to the UITour API), we can re-visit isFirefoxUpToDate's detection methods.
Comment 10 User image Kohei Yoshino [:kohei] 2015-01-23 13:52:50 PST
I haven't followed the discussion in detail, but as far as I see Bug 1122154, the decision looks like "we don't treat Firefox 31 as up-to-date" and NOT "we don't treat Firefox ESR as up-to-date". Those are different things.

I think Bug 1122154 hasn't solved the real issue.

Here's a patch for this bug and Bug 1122154 could be solved the same way:
https://github.com/kyoshino/bedrock/compare/bug-1125166-tabzilla-esr
Comment 11 User image Alex Gibson [:agibson] 2015-01-23 14:01:59 PST
It was my understanding that relying on hard coded build numbers was not something we we're going to commit to, until a time when we could more easily distinguish all ESR users (hence Bug 1122154). Maybe I've missed some part of this discussion however, which has certainly been long and on-going.
Comment 12 User image Kohei Yoshino [:kohei] 2015-01-23 14:15:52 PST
Of course the hardcoded build ID is a tentative solution. Once Firefox 38 is released, we can use the mozUITour API. Once Firefox 31 goes ESR, we can remove the hardcoded solution. We don't have to maintain the non-ESR 31 build ID since it's already fixed.
Comment 13 User image Alex Gibson [:agibson] 2015-01-23 14:19:42 PST
If we're at a time when we can do this reliably without tentative maintenance and this property is not at risk of being changed or removed, then I think we're ok. +1
Comment 14 User image Alex Gibson [:agibson] 2015-01-23 14:42:32 PST
As a related note for future work on this (which we can carry on in other bugs), I think going forward we also need to carefully consider if we should become reliable on ui tour api for determining if users are up to date. There are various ways and reasons for uitour not to work on some profiles. We should avoid using it in ways that might actually prevent users from downloading Firefox if it fails.
Comment 15 User image Kohei Yoshino [:kohei] 2015-01-23 14:53:36 PST
So the navigator.buildID might still be useful to detect Firefox 38 ESR.
Comment 16 User image Alex Gibson [:agibson] 2015-01-23 14:58:22 PST
If we do use UI-tour API in the future, it should probably be a form of “progressive enhancement” only. The user should always get a download button if the callback never executes. But we can tackle this further down the line…
Comment 17 User image Kohei Yoshino [:kohei] 2015-01-23 14:59:21 PST
Created attachment 8554003 [details] [review]
pull request
Comment 18 User image [github robot] 2015-01-27 04:40:58 PST
Commits pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/2bee1fd25be11f981a205fd3775c524c06ccffb3
Fix Bug 1125166 - Some mozilla.org-sites consider 31.4ESR to be out of date

https://github.com/mozilla/bedrock/commit/42c7a4bd588243afb65eac57472d0a4a4d414ec9
Merge pull request #2680 from kyoshino/bug-1125166-tabzilla-esr

Fix Bug 1125166 - Some mozilla.org-sites consider 31.4ESR to be out of date
Comment 19 User image Kohei Yoshino [:kohei] 2015-01-28 02:43:49 PST
A quick note: there are still a few edge cases where ESR 31 is falsely detected:

* Pre-release versions of Firefox 31 (Nightly, Aurora and Beta)
* Semi-official & Unofficial versions of Firefox 31 (e.g. Ubuntu build by Canonical)

... because those builds have a different build ID from the official release version.

But here, users are just not seeing the Update Bar, so I believe it won't be a problem.
Comment 20 User image Alex Gibson [:agibson] 2015-01-28 02:46:14 PST
(In reply to Kohei Yoshino [:kohei] from comment #19)
> A quick note: there are still a few edge cases where ESR 31 is falsely
> detected:
> 
> * Pre-release versions of Firefox 31 (Nightly, Aurora and Beta)
> * Semi-official & Unofficial versions of Firefox 31 (e.g. Ubuntu build by
> Canonical)
> 
> ... because those builds have a different build ID from the official release
> version.
> 
> But here, users are just not seeing the Update Bar, so I believe it won't be
> a problem.

Thanks Kohei, this is good to know when considering the use of buildID's in other places. We may have to tread more carefully.
Comment 21 User image Kohei Yoshino [:kohei] 2015-01-28 02:57:16 PST
Yes, Bug 939470 for /firefox/new/ is still open, and as I proposed in the bug we could use a neutral messaging in such cases.

Note You need to log in before you can comment on or make changes to this bug.