+++ This bug was initially created as a clone of Bug #1315153 +++ Title: System Unsupported Message: Your Firefox is out of date, but the latest version is not supported on your system. Please upgrade your system, then try again. You will not see this notice again, but you can learn more. Note: The "learn more" text is the link.

I'd like to get a clear understanding of what the plan is for this message (and bug 1319164). As explained in another discussion, we can't have strings landing in-product after it moves out of Aurora. And, if we want to localize it through the standard channel, we need to land the strings as soon as possible in mozilla-aurora. The alternative is to build a system add-on, and that would also let you change the message over time, independently from trains.

(In reply to Francesco Lodolo [:flod] from comment #1) > I'd like to get a clear understanding of what the plan is for this message > (and bug 1319164). > > As explained in another discussion, we can't have strings landing in-product > after it moves out of Aurora. And, if we want to localize it through the > standard channel, we need to land the strings as soon as possible in > mozilla-aurora. > > The alternative is to build a system add-on, and that would also let you > change the message over time, independently from trains. Please keep in mind that according to telemetry system add-ons have not been reliably pushed out to clients. The exception to this is if the system add-on is included in the build itself but I don't think that is what is being proposed. Unless it is shown that the several examples of system add-ons not successfully being pushed to clients is somehow false or there is a fix for this issue (note: if it is a client side issue I don't think it will make it into esr) I don't think a system add-on is a viable method to accomplish this messaging. See bug 1307568 for more information.

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #2) > Please keep in mind that according to telemetry system add-ons have not been > reliably pushed out to clients. I'm aware of that issue, sadly that doesn't change our localization infrastructure. We might be able to fix some languages on Beta (we shouldn't), but we technically can't ship localization updates to ESR or release. Pike is working on that, but it won't be ready for 52. My understanding is that a good portion of the XP population is not on English builds, which makes localization even more important. As for the system add-ons: Pocket is shipping as part of the build, but its strings live in an external GitHub repository https://github.com/mozilla-l10n/pocket-l10n They're then dumped into the main code base, just in a path not exposed to localization tools (see bug 1304151) https://dxr.mozilla.org/mozilla-beta/source/browser/extensions/pocket/locale That gets rid of the train limitation. It's not ideal, but it's the best we have at the moment.

I'm in complete agreement with you flod in regards to the l10n. I just want to make sure that system add-ons aren't expected to reliably be pushed to clients especially since many people have expected that they can be. If they are included in the build that should suffice as I stated in my comment.

Sorry for the delay, folks. For this particular message, we will simply use the de-support xml notice that is already in the product - that is, no need for new localization. I'm told release management can trigger it via an xml file. I'll update the other bugs to describe the new plan as well (which also won't require localization in the product).

[Tracking Requested - why for this release]: Firefox 52 was the last Nightly and Aurora version to support XP/Vista, so we need tell these users.

Tracking 53+ for the reasoning in Comment 6.

We can show a desupport warning using the update server, similar to OSX 10.6-10.8 desupport. I can set up this any time for mozilla-central nigtlies, but it'd be great to have a SUMO page that we can point these users to.

Added link to SUMO article to user story

I set up the "nightly-xp" update channel to advertise the desupport message on any platform (just to test how it looks like). You can edit defaults/pref/channel-prefs.js and set the channel to "nightly-xp" to reproduce it. Basically there is no additional pop-up, new tab, etc. It's just a special message in the About dialog. https://people-mozilla.org/~raliiev/sattap/a757b977.png

(In reply to Rail Aliiev [:rail] ⌚️ET from comment #10) > I set up the "nightly-xp" update channel to advertise the desupport message > on any platform (just to test how it looks like). You can edit > defaults/pref/channel-prefs.js and set the channel to "nightly-xp" to > reproduce it. > > Basically there is no additional pop-up, new tab, etc. It's just a special > message in the About dialog. > > https://people-mozilla.org/~raliiev/sattap/a757b977.png Does the about dialog pop-up or does it need to be manually opened to see this?

Yes, I had to click on "Learn more".

See bug 843497 https://bug843497.bmoattachments.org/attachment.cgi?id=765799 and https://bug843497.bmoattachments.org/attachment.cgi?id=765812 The first one is displayed to the user once. More details I believe are described in the bug.

I don't recall whether the first one is displayed if the user sees the one in the about dialog but I think it is still displayed once. It is displayed after the background update check is performed.

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #14) > I don't recall whether the first one is displayed if the user sees the one > in the about dialog but I think it is still displayed once. It is displayed > after the background update check is performed. Thanks Robert. Just to be crystal clear: If the user never manually goes into the About screen, will some UI (like https://bug843497.bmoattachments.org/attachment.cgi?id=765812) pop up for them? In the cited bug you indicated "the update dialog is a notification and all users will see it".

(In reply to Peter Dolanjski [:pdol] from comment #15) > (In reply to Robert Strong [:rstrong] (use needinfo to contact me) from > comment #14) > > I don't recall whether the first one is displayed if the user sees the one > > in the about dialog but I think it is still displayed once. It is displayed > > after the background update check is performed. > > Thanks Robert. Just to be crystal clear: If the user never manually goes > into the About screen, will some UI (like > https://bug843497.bmoattachments.org/attachment.cgi?id=765812) pop up for > them? In the cited bug you indicated "the update dialog is a notification > and all users will see it". The following UI will be displayed https://bug843497.bmoattachments.org/attachment.cgi?id=765799 Just checked... it is displayed to all clients that have updates enabled and receive the unsupported update xml one time.

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #16) > (In reply to Peter Dolanjski [:pdol] from comment #15) > > (In reply to Robert Strong [:rstrong] (use needinfo to contact me) from > > comment #14) > > Thanks Robert. Just to be crystal clear: If the user never manually goes > > into the About screen, will some UI (like > > https://bug843497.bmoattachments.org/attachment.cgi?id=765812) pop up for > > them? In the cited bug you indicated "the update dialog is a notification > > and all users will see it". > The following UI will be displayed > https://bug843497.bmoattachments.org/attachment.cgi?id=765799 > > Just checked... it is displayed to all clients that have updates enabled and > receive the unsupported update xml one time. Excellent. Thanks for verifying!

Rail, now that our SUMO page about XP/Vista EOL is live, can you please send the "System Unsupported" message to XP and Vista users on Nightly 53 and Aurora 52? Can you customize the message's "Learn more" link to point to our SUMO page? Our SUMO page's URL template looks like this: https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/xp-eol which should point to this real SUMO page on my en-US machine: https://support.mozilla.org/en-US/kb/end-support-windows-xp-and-vista

comment 18 is done now

Thanks, Rail. How can I test this? I changed my UA to spoof Windows XP running Aurora 52 ("Mozilla/5.0 (Windows NT 5.1; rv:52.0) Gecko/20100101 Firefox/52.0") and then opened the About dialog to force an update check, but I didn't receive a desupport notice.

The UA isn't the source for the Windows version info. To test properly you will need to be running XP. If you just want to verify that balrog is sending the correct update.xml you can set the app.update.log preference to true, perform an update check, get the update url from the browser console (iirc it will be prefixed with 'AUS:SVC' and contain getUpdateURL), modify the url so it is for XP (I think Windows version number would do it), and open that url to see the contents.

Thanks, Robert. Rail, I don't receive a desupport notice from balrog when spoofing XP or Vista. Here is my real update.xml URL: https://aus5.mozilla.org/update/6/Firefox/53.0a1/20170104004006/WINNT_x86-msvc-x64/en-US/nightly/Windows_NT%2010.0.0.0%20(x64)(noBug1296630v1)/SSE3/default/default/update.xml?force=1 If I spoof XP (NT 5.1), I receive an empty <updates></updates> response. I assume my spoof URL is wrong: https://aus5.mozilla.org/update/6/Firefox/53.0a1/20170104004006/WINNT_x86-msvc-x64/en-US/nightly/Windows_NT%205.1.0.0%20(x64)(noBug1296630v1)/SSE3/default/default/update.xml?force=1 But if I spoof any version later than XP (e.g. Vista NT 6.0 or even NT 5.2 aka "Windows XP Professional x64"), then I receive a standard update response, even though I would expect a desupport notice for NT < 6.1 (aka Windows 7): https://aus5.mozilla.org/update/6/Firefox/53.0a1/20170104004006/WINNT_x86-msvc-x64/en-US/nightly/Windows_NT%206.0.0.0%20(x64)(noBug1296630v1)/SSE3/default/default/update.xml?force=1

We have a watershed to update all XP users with Build ID < 20161118030222 to 20161118030222. After you update to 20161118030222 you'll get the desupport message. Also XP/Vista use only one dot in the version (Windows_NT 5.1 ,Windows_NT 5.2, Windows_NT 6.0), at least this is how the watershed was set up initially. See https://aus5.mozilla.org/update/6/Firefox/53.0a1/20161118030222/WINNT_x86-msvc-x64/en-US/nightly/Windows_NT%205.1%20(x64)(noBug1296630v1)/SSE3/default/default/update.xml?force=1

Looks good. Thanks for walking me through update message process. Resolving fixed for 53.

The title includes Dev edition, which is still 52. Want me to file a separate bug or reopen this one?

(In reply to Rail Aliiev [:rail] ⌚️ET from comment #25) > The title includes Dev edition, which is still 52. Want me to file a > separate bug or reopen this one? If we do nothing, will Dev Edition users receive the 53 desupport notice when we merge 53 from Nightly to Aurora? If so, that's probably good enough (since 52 technically still supports XP and Vista).

aurora is a separate update channel and requires a separate desupport rule. Let me reopen this and assign to myself to sort out required changes in ~3 weeks, when we uplift m-c to m-a

this is now live: * watershed: current XP/2003/Vista users <20170123004004 (the last 52.0 aurora nightly) will get 20170123004004 * XP/2003/Vista users who are on 20170123004004 won't get further updates but instead get directed to XP-Vista-Desupport[1] closing this for now [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1318920#c3

(In reply to Jordan Lund (:jlund) from comment #28) > * watershed: current XP/2003/Vista users <20170123004004 > (the last 52.0aurora nightly) will get 20170123004004 My OS is Windows Vista SP2 32bit (en-US locale), fully patched. I have kept a portable (PAF) installation of Firefox Nightly 52.0a1 (x86), being currently at buildID=20161111030203; I have disabled updates. Up to a while ago, when I manually initiated an update check Help -> About Firefox -> Check for updates the "watershed" described in comment 23 would kick in and I would be prompted to "Update to 53.0a1" (specifically buildID=20161118030222). Today, the same manual check prompts me to "Update to 54.0a1", see screenshot: http://i.imgur.com/MPbn8F4.jpg Of course, 54.0a1 won't run on Vista, so can someone please shed some light on this change in behaviour from the update server?

this was my fault, a regression while making the change. Apologies. Rail has fixed it now so it won't happen again but we will certainly have X amount of users who received a 54.0 update over the last few hours. Particularly those who manually checked.

(In reply to Jordan Lund (:jlund) from comment #30) I filed bug 1241766 a while ago and have reiterated the importance of having a bug like it here: https://bugzilla.mozilla.org/show_bug.cgi?id=1241766#c1 implementing this would block people like me from making such a human error

(In reply to Jordan Lund (:jlund) from comment #30) > this was my fault, a regression while making the change. Apologies. > Rail has fixed it now so it won't happen again ... Thank you, I guess, but the previous behaviour already described in comment 23 hasn't been restored: When I now manually initiate an update check from within 52.0a1_20161111030203, I am not (thankfully) prompted to update to 54.0a1, but am directly receiving the "You can not perform further updates on this system. Learn more" message: http://i.imgur.com/BBRDeiX.jpg To re-iterate, previously I would've received this message ONLY AFTER having first updated to 53.0a1_20161118030222 (not straight from within a 52.0a1 build...)

(In reply to Vangelis from comment #32) > (In reply to Jordan Lund (:jlund) from comment #30) > To re-iterate, previously I would've received this message ONLY AFTER having > first updated > to 53.0a1_20161118030222 (not straight from within a 52.0a1 build...) sorry, I should have been more explicit. The watershed rules that were in place to get everyone to 20161118030222 were only temporary. For watersheds like these, after a certain amount of time on nightlies (>30 days), where we think we have served enough users to 20161118030222, we simplify the update complexity so that we remove the watershed and fallback on the blanket rule that catches all xp/vista nightly users, informing them we are no longer providing nightly updates, this is page that you are seeing and linked to in comment 32.

(In reply to Jordan Lund (:jlund) from comment #33) > and fallback on the blanket rule that catches all xp/vista nightly users, > informing them we are no longer providing nightly updates, > this is (the) page that you are seeing and linked to in comment 32. If an XP/Vista user now tries manually to update Firefox Nightly 52.0a1 and/or Firefox Developer Edition 52.0a2, no matter the actual buildIDs, will fall, as you say, on the blanket rule and receive the unsupported OS notification: "You can not perform further updates on this system. Learn more" Screengrab for Nightly => http://i.imgur.com/BBRDeiX.jpg HOWEVER, after the recent migration of SUMO (from Kitsune to Lithium), the "Learn more" link on the notification window DOES NOT WORK; when clicked, the browser tries to reach https://support.mozilla.org/1/firefox/52.0/win/en-US/xp-eol but this results in a (404) message: "The page you are trying to access was not found. Please check your URL for typos and try again." which doesn't enlighten the XP/Vista user one bit... :-( I think the original link should be changed to the following "Lithium" SUMO entry: https://support.mozilla.org/t5/Install-and-Update/Important-Firefox-is-ending-support-for-Windows-XP-and-Vista/ta-p/31270 Feel free to open a bug that will rectify things...

(In reply to Vangelis from comment #34) > HOWEVER, after the recent migration of SUMO (from Kitsune to Lithium), the > "Learn more" > link on the notification window DOES NOT WORK; when clicked, the browser > tries to reach > > https://support.mozilla.org/1/firefox/52.0/win/en-US/xp-eol > > but this results in a (404) message: ... > > I think the original link should be changed to the following "Lithium" SUMO > entry: > > https://support.mozilla.org/t5/Install-and-Update/Important-Firefox-is- > ending-support-for-Windows-XP-and-Vista/ta-p/31270 Joni, does the SUMO migration from "Kitsune" to "Lithium" break all old SUMO URLs? Will we need to use the new "Lithium" URLs?

This is still redirecting people to a 404. https://hg.mozilla.org/releases/mozilla-esr52/ now exists but I don't see any candidate builds yet. For now, maybe an XML update to point to the right URL, or a server-side redirect? Or a set of them, if there are localization considerations? Note that other sites will have been pointing to the URL(s) as well, e.g. news sites and blogs. [Incidentally, https://www.mozilla.org/en-US/firefox/organizations/all/ doesn't even download ESR 45 for 32-bit Windows; you get 38 builds if you try. Confusing, as win32 builds exist. I thought it might be because of processor support but https://support.mozilla.org/t5/Install-and-Update/Your-hardware-is-no-longer-supported/ta-p/39389 indicates that is not the case. Maybe SHA-1 fallout?]

(In reply to Laurence "GreenReaper" Parry from comment #36) > This is still redirecting people to a 404. > For now, maybe an XML update to point to the right URL, or a server-side > redirect? We're working on a server-side fix for this URL now. It should handle localization, too. > [Incidentally, https://www.mozilla.org/en-US/firefox/organizations/all/ > doesn't even download ESR 45 for 32-bit Windows; you get 38 builds if you > try. Confusing, as win32 builds exist. I thought it might be because of > processor support but > https://support.mozilla.org/t5/Install-and-Update/Your-hardware-is-no-longer- > supported/ta-p/39389 indicates that is not the case. Maybe SHA-1 fallout?] @ Rail, I can reproduce this problem. If I change my User-Agent string to NT 5.1 (XP) and load the ESR download page, mousing over the 32-bit Windows download links shows a URL pointing to 45.7.0esr but clicking the link downloads the 38.5.1esr installer exe. Is this expected?

(In reply to Chris Peterson [:cpeterson] from comment #37) > @ Rail, I can reproduce this problem. If I change my User-Agent string to NT > 5.1 (XP) and load the ESR download page, mousing over the 32-bit Windows > download links shows a URL pointing to 45.7.0esr but clicking the link > downloads the 38.5.1esr installer exe. Is this expected? Can you provide the actual link that looks like esr45?

Oh, I just realized that we never shipped SHA1 signed ESR45 installers. This is why we still point XP/Vista users to ES38. ESR52 will fix this issue.

(In reply to Rail Aliiev [:rail] ⌚️ET from comment #38) > Can you provide the actual link that looks like esr45? https://download.mozilla.org/?product=firefox-45.7.0esr-SSL&os=win&lang=ach

(In reply to Chris Peterson [:cpeterson] from comment #40) > (In reply to Rail Aliiev [:rail] ⌚️ET from comment #38) > > Can you provide the actual link that looks like esr45? > > https://download.mozilla.org/?product=firefox-45.7.0esr-SSL&os=win&lang=ach Yup, thanks. As I mentioned in comment 39, this is expected now.

(In reply to Chris Peterson (:cpeterson) from comment #35) > Joni, does the SUMO migration from "Kitsune" to "Lithium" break all old SUMO > URLs? Will we need to use the new "Lithium" URLs? Clearing this obsolete needinfo. We shipped this UI warning last year.