User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0 (Beta/Release) Build ID: 20121128204232 Steps to reproduce: going to http://www.mozilla.org/en-US/firefox/new/ Actual results: tells me that I have the up to date firefox version Expected results: should not lie to the user, as the firefox is not the newest version

No need to keep this hidden as it limits the people who can see it. It appears we do not take into account navigator.buildID and treat the ESR version as up to date even if it is an older version.

I think this is the expected behavior for ESR builds. I'm going to close this bug.

This is still valid, and the solution is Bug 988725.

I'll work on this next week along with Bug 935719.

Given that we have bug 935719 resolved, can we use the ability in bug 1065525 to determine "isFirefoxUpToDate" that includes the full version number instead of just major versions. Currently, when the UA returns 33.0, the user could be running 33.0.1 or 33.1 and we have no idea if the are really up to date. With dot releases or chemspills, this happens quite often. What do you recommend?

More info on this bug with a recent duplicate bug 1096514.

The only solution we can currently rely on is the window.navigator.buildID DOM property (I wrote about it somewhere else). For example, Firefox 33.1 returns "20141106120505" while 33.1.1 returns "20141113143407" so these builds are distinguishable. But the information have to be maintained manually by the RelEng team or Bedrockers. IMO waiting for Firefox 35 until January 13 is a realistic approach at this time.

Or we could request the uplift of Bug 1065525 to Firefox 34 which will be shipped next week.

I haven't seen this bug in a while, so its fixed. I would much rather you fix the long standing "huge-ass memory leak that can lock up my computer by just visiting the wrong url" bug, otherwise known as bug 984362. It even happens on the mobile.

Reopening. When I go to http://www.mozilla.org/en-US/firefox/new/ using Firefox 33.1 I see "Congrats! You’re using the latest version of Firefox" even though Firefox 33.1.1 was released November 14, 2014.

Yes, this should still be a problem, because 33.0, 33.0.1. 33.0.2, 33.0.3, 33.1, 33.1.1 are all treated as the same version. Since it was too late for Bug 1065525 to be uplifted to 34, this bug would be fixed when 35 is out in January. I'll send a pull request to make necessary changes after 35 goes beta.

Firefox 35 is out today. I'll send a pull request this week.

I have revisited here -- until Firefox 31 goes end-of-life, this issue is difficult to be simply resolved because the mozUITour API is available only on 35 and later. One solution is using navigator.buildID but I don't want to maintain the value every 6 week. https://wiki.mozilla.org/Releases/Firefox_31_ESR/Test_Plan How about just saying "Thank you for using Firefox!" to ESR users, so at least they don't have to see the wrong "You’re using the latest version" message.

My proposal looks like this: https://github.com/kyoshino/bedrock/compare/bug-939470-firefox-new-esr

Comment on attachment 8554051 [details] Screenshot showing the proposed message Firefox 31 ESR detection has been landed to Tabzilla in Bug 935719, so now it might be safe to do the same thing on /firefox/new/ to solve this bug. How do you think of the message?

(In reply to Kohei Yoshino [:kohei] from comment #21) > Firefox 31 ESR detection has been landed to Tabzilla in Bug 935719 I meant Bug 1125166.

(In reply to Kohei Yoshino [:kohei] from comment #21) > Comment on attachment 8554051 [details] > Screenshot showing the proposed message > > Firefox 31 ESR detection has been landed to Tabzilla in Bug 935719, so now > it might be safe to do the same thing on /firefox/new/ to solve this bug. > How do you think of the message? Hi Kohei, the message next to the green check mark is meant to serve as conditional messaging to tell a user if they are or are not up to date. If we are not using it for this purpose, I hesitate to use it to serve another type of message. Do you know if the solution discussed in the following bug comment was implemented and if so, why we may now want to do something different? https://bugzilla.mozilla.org/show_bug.cgi?id=952549#c30 I'm curious if there is an additional problem that was discovered after implementing the solution described in that bug.

(In reply to Holly Habstritt Gaal [:Habber] from comment #23) > Do you know if the solution discussed in the following bug comment was > implemented and if so, why we may now want to do something different? > https://bugzilla.mozilla.org/show_bug.cgi?id=952549#c30 I think the issue discussed in Bug 952549 still exists. We can now detect: * ESR 31 users, as implemented in Bug 935719 * the channel and minor version on Firefox 35+, using the mozUITour API but there is still no effortless way to detect: * if the user is on the latest 31 ESR (31.4.0) or not (31.3.0) So implementing the message :Habber proposed in Bug 952549 Comment 30, which falls into the last case, is still difficult and that's why we probably need some "neutral" message as I proposed in Comment 18. Problems will be solved once 31 ESR goes end-of-life, but looks like there are edge cases where the mozUITour API doesn't work as expected, so a neutral message might still be needed anyway rather than saying "latest" nor "outdated". Thoughts?

A neutral message is probably a good idea when we cannot accurately say 100% you are out of date or latest.

(In reply to Kohei Yoshino [:kohei] from comment #24) > (In reply to Holly Habstritt Gaal [:Habber] from comment #23) > > Do you know if the solution discussed in the following bug comment was > > implemented and if so, why we may now want to do something different? > > https://bugzilla.mozilla.org/show_bug.cgi?id=952549#c30 > > I think the issue discussed in Bug 952549 still exists. > > We can now detect: > > * ESR 31 users, as implemented in Bug 935719 > * the channel and minor version on Firefox 35+, using the mozUITour API > > but there is still no effortless way to detect: > > * if the user is on the latest 31 ESR (31.4.0) or not (31.3.0) > > So implementing the message :Habber proposed in Bug 952549 Comment 30, which > falls into the last case, is still difficult and that's why we probably need > some "neutral" message as I proposed in Comment 18. > > Problems will be solved once 31 ESR goes end-of-life, but looks like there > are edge cases where the mozUITour API doesn't work as expected, so a > neutral message might still be needed anyway rather than saying "latest" nor > "outdated". > > Thoughts? Hi Kohei, what kind of work is involved to do the following: Detect if the user is on the latest 31 ESR (31.4.0) or not (31.3.0) This continues to be an issue that is hard to work around and it would be nice to solve it properly, so we are confident that the right users receive he right messaging and next step. I don't feel comfortable using the Notification message area for a neutral message. It still doesn't solve the user's issue. The user came here to download Firefox, so we should give them an answer to why they cannot complete this task. Otherwise this page has no value to them and leaves them hanging, with no next step, task not completed, and questions we have not answered. If it is out of the question that we would ever be able to detect if the user is on the latest ESR?

* edit to my last question: Is it out of the question that we would ever be able to detect if the user is on the latest ESR?

Detecting if the user is on the latest 31 ESR (31.4.0) or not (31.3.0) is *possible* with the browser's latest build ID (14 digit number) which can be found here: https://wiki.mozilla.org/Releases/Firefox_31_ESR/Test_Plan The detection code is actually simple: currently if the user's browser build ID is 20150105205548, he/she is on the latest ESR (31.4.0), otherwise outdated. But someone has to update the ID data on mozilla.org every 6 weeks at least until ESR 31 goes end-of-life this August...

Bugzilla says needinfo on this bug and I don't see it when I visit the bug. Hmm. Going to try to save again.

Ah! It is on the attachment.

Comment on attachment 8554051 [details] Screenshot showing the proposed message Why not just show the refresh button for up-to-date ESR visitors instead of yet another message?

Comment on attachment 8554051 [details] Screenshot showing the proposed message Clear needinfo

(In reply to Chris More [:cmore] from comment #31) > Why not just show the refresh button for up-to-date ESR visitors instead of > yet another message? Detecting the up-to-date ESR requires the latest build ID, and as I said in Comment 18, it involves a maintenance every 6 week. As there are only 4 more 31 ESR releases, I can volunteer to handle that if other Bedrockers agree with that approach.

(In reply to Kohei Yoshino [:kohei] from comment #33) > (In reply to Chris More [:cmore] from comment #31) > > Why not just show the refresh button for up-to-date ESR visitors instead of > > yet another message? > > Detecting the up-to-date ESR requires the latest build ID, and as I said in > Comment 18, it involves a maintenance every 6 week. As there are only 4 more > 31 ESR releases, I can volunteer to handle that if other Bedrockers agree > with that approach. As ESR Release Owner I want to chime in and say this would be great!

I was just thinking maybe this is something we can build into shipit in the future so it automatically updates these buildid's?

If someone can put and update the BuildID in the product details, that's would be great. http://viewvc.svn.mozilla.org/vc/libs/product-details/ For Firefox 38 ESR and later, we can use the mozUITour API (Bug 1065525) so the BuildID info will no longer be required to detect the latest ESR version.

(In reply to Kohei Yoshino [:kohei] from comment #36) > If someone can put and update the BuildID in the product details, that's > would be great. > > http://viewvc.svn.mozilla.org/vc/libs/product-details/ > > For Firefox 38 ESR and later, we can use the mozUITour API (Bug 1065525) so > the BuildID info will no longer be required to detect the latest ESR version. Sylvestre, would this be possible?

We are working on killing the product details. I don't think we should add more stuff into it. I am currently working on bug 1083718 to move the data from the svn repo to ship-it. However, I don't think we have access to the BuildID from this database (but I think it should not be too hard to add).

I think it's too late to deal with 31 ESR as it goes the EOL in only 3 months. I have filed Bug 1164440 so that 38 ESR users won't see the wrong message.

Since there is mainly discussion of esr in this bug I want to make sure it is understood that bug 1078341 which has been duped to this bug was using a release build and not an esr build.

Yes, ESR has mostly been discussed here, but the minor versions of the release channel are also affected. There are 2 issues need to be solved: * We are checking only the major version of the browser, so Firefox 38.0.5 users will see the wrong "up-to-date" message. * We are treating 2 previous major versions as the latest version, so Firefox 36 and 37 users will also see the wrong message. I'll work on this before heading to Whistler.

(In reply to Kohei Yoshino [:kohei] from comment #42) > * We are checking only the major version of the browser, so Firefox 38.0.5 > users will see the wrong "up-to-date" message. I meant 38.0 and 38.0.1 users.

We can fit this without the Ship It data.

(In reply to Kohei Yoshino [:kohei] from comment #42) > Yes, ESR has mostly been discussed here, but the minor versions of the > release channel are also affected. There are 2 issues need to be solved: > > * We are checking only the major version of the browser, so Firefox 38.0.5 > users will see the wrong "up-to-date" message. > * We are treating 2 previous major versions as the latest version, so > Firefox 36 and 37 users will also see the wrong message. We are now up to ESR 38.3.0. Is it possible to fix this now ? (I believe that the subject line is now the wrong way round; https://www.mozilla.org/en-US/firefox/new/ gives "Looks like you’re using an older version of Firefox." with the latest ESR version.) Thanks,

Sorry I'm late. Yes, we should be able to do it now. I'll work on this next week.

According to today's Vidyo meeting, this change requires further discussion with wider stakeholders because the /firefox/new/ page requires special attention to the UX. Technically there are only 2 states, up-to-date or outdated, but the messaging here could vary. Also, we still need some tests to make sure the async API is working well. Bug 1216225 is to make the change except to /firefox/new/ so we can collect some data from other non-critical pages via Google Analytics.