1125166 - Some mozilla.org-sites consider 31.4ESR to be out of date

Status: RESOLVED FIXED

(Websites :: Tabzilla, defect)

Description

[Elbart]

Attachment: 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

[Kohei Yoshino]

That's the Update Bar I have implemented on Tabzilla :( Will figure out why.

Comment 2

[Kohei Yoshino]

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

[Kohei Yoshino]

This was my initial proposal for Bug 935719:
https://github.com/kyoshino/bedrock/compare/tabzilla-updatebar

Comment 4

[Alex Gibson [:agibson]]

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

[Kohei Yoshino]

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

[Alex Gibson [:agibson]]

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

[Kohei Yoshino]

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

[Alex Gibson [:agibson]]

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

[Jonathan Petto [:jpetto]]

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

[Kohei Yoshino]

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

[Alex Gibson [:agibson]]

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

[Kohei Yoshino]

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

[Alex Gibson [:agibson]]

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

[Alex Gibson [:agibson]]

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

[Kohei Yoshino]

So the navigator.buildID might still be useful to detect Firefox 38 ESR.

Comment 16

[Alex Gibson [:agibson]]

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

[Kohei Yoshino]

Attachment: pull request

Comment 18

[[github robot]]

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

[Kohei Yoshino]

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

[Alex Gibson [:agibson]]

(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

[Kohei Yoshino]

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.