User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Started up Firefox. Or left it unused for a while.

Actual results:

Firefox ESR 68.0.1 (64bit Linux) continually notifies the user "Update available. Install?" when in fact no such Firefox-ESR update is available, and in fact when the installation is by root and the user is not root.

Expected results:

Notifications only for Firefox-ESR updates, probably only to root.

(In reply to carlie@jyarborough.com from comment #0)

Firefox ESR 68.0.1

The current version is Firefox 68.2.0esr. If you use the version from your distro, it might be behind, but otherwise there's definitely an update available.

• https://www.mozilla.org/firefox/organizations/all/

Notifications only for Firefox-ESR updates, probably only to root.

It's not possible to run Firefox as root (bug 1460297). Bug 529748 is probably the best fit here.

But 1) firefox certainly can be installed by root:

% ls -l `which firefox`
lrwxrwxrwx 1 root root 20 Dec  8  2015 /opt/bin/firefox -> /opt/firefox/firefox*

and 2) When one clicks on the "download" button on the notice, the version downloaded is NON-ESR 70.1.something.
Which is not a correct firefox-esr update.

The priority flag is not set for this bug.
:rstrong, could you have a look please?

For more information, please visit auto_nag documentation.

Please type about:config in the url bar, click the button to display the content, type app.update.log in the search box that is displayed, and change the app.update.log entry so the value is true. Open Tools -> Web Developer -> Browser Console. Click the Trash button. In the Firefox window select Help -> About Firefox. In the Browser Console you previously opened please copy / pastes the entries that start with "AUS: " into into this bug report.

AUS:SVC Checker: checkForUpdates, force: true
AUS:SVC UpdateService.canCheckForUpdates - able to check for updates
AUS:SVC Checker:getUpdateURL - update URL: https://aus5.mozilla.org/update/6/Firefox/68.3.0/20191126000427/Linux_x86_64-gcc3/en-US/esr/Linux%205.3.13-desktop-2.mga7%20(GTK%203.24.8%2Clibpulse%2012.2.0)/ISET:SSE4_2,MEM:7934/default/default/update.xml?force=1
AUS:SVC Checker:checkForUpdates - sending request to: https://aus5.mozilla.org/update/6/Firefox/68.3.0/20191126000427/Linux_x86_64-gcc3/en-US/esr/Linux%205.3.13-desktop-2.mga7%20(GTK%203.24.8%2Clibpulse%2012.2.0)/ISET:SSE4_2,MEM:7934/default/default/update.xml?force=1
AUS:SVC Checker:onLoad - request completed downloading document
AUS:SVC Checker:onLoad - Getting sslStatus failed.
AUS:SVC Checker:onLoad - number of updates available: 0

There's nothing in those logs that is indicative of the problem. The next time this happens please open the browser console and copy / paste the entries that start with AUS: and any errors that might be applicable

Running ESR 68.3.0. It would seem that there is now an ESR 68.4.0; on the other hand, the proffered download from the popup talks about non-ESR 72.0. Hope that helps
-- Carlie

UTM:SVC TimerManager:notify - notified @mozilla.org/browser/search-service;1
AUS:SVC getCanApplyUpdates - testing write access /opt/firefox/update.test
AUS:SVC getCanApplyUpdates - unable to apply updates without write access to the update directory. Exception: [Exception... "Component returned failure code: 0x80520015 (NS_ERROR_FILE_ACCESS_DENIED) [nsIFile.create]" nsresult: "0x80520015 (NS_ERROR_FILE_ACCESS_DENIED)" location: "JS frame :: resource://gre/modules/UpdateService.jsm :: testWriteAccess :: line 303" data: no]
AUS:SVC There is currently no implementation for fixing update directory permissions on this platform
UTM:SVC TimerManager:notify - notified @mozilla.org/updates/update-service;1
AUS:SVC Checker:getUpdateURL - update URL: https://aus5.mozilla.org/update/6/Firefox/68.3.0/20191126000427/Linux_x86_64-gcc3/en-US/esr/Linux%205.3.13-desktop-2.mga7%20(GTK%203.24.8%2Clibpulse%2012.2.0)/ISET:SSE4_2,MEM:7934/default/default/update.xml
AUS:SVC UpdateService.canCheckForUpdates - able to check for updates
AUS:SVC Checker: checkForUpdates, force: false
AUS:SVC UpdateService.canCheckForUpdates - able to check for updates
AUS:SVC Checker:getUpdateURL - update URL: https://aus5.mozilla.org/update/6/Firefox/68.3.0/20191126000427/Linux_x86_64-gcc3/en-US/esr/Linux%205.3.13-desktop-2.mga7%20(GTK%203.24.8%2Clibpulse%2012.2.0)/ISET:SSE4_2,MEM:7934/default/default/update.xml
AUS:SVC Checker:checkForUpdates - sending request to: https://aus5.mozilla.org/update/6/Firefox/68.3.0/20191126000427/Linux_x86_64-gcc3/en-US/esr/Linux%205.3.13-desktop-2.mga7%20(GTK%203.24.8%2Clibpulse%2012.2.0)/ISET:SSE4_2,MEM:7934/default/default/update.xml
AUS:SVC Checker:onLoad - request completed downloading document
AUS:SVC Checker:onLoad - Getting sslStatus failed.
AUS:SVC Checker:onLoad - number of updates available: 1
AUS:SVC getCanApplyUpdates - testing write access /opt/firefox/update.test
AUS:SVC getCanApplyUpdates - unable to apply updates without write access to the update directory. Exception: [Exception... "Component returned failure code: 0x80520015 (NS_ERROR_FILE_ACCESS_DENIED) [nsIFile.create]" nsresult: "0x80520015 (NS_ERROR_FILE_ACCESS_DENIED)" location: "JS frame :: resource://gre/modules/UpdateService.jsm :: testWriteAccess :: line 303" data: no]
AUS:SVC There is currently no implementation for fixing update directory permissions on this platform
AUS:SVC UpdateService:_selectAndInstallUpdate - the user is unable to apply updates... prompting. Notifying observers. topic: update-available, status: cant-apply
UTM:SVC TimerManager:notify - notified timerID: browser-cleanup-thumbnails

(In reply to carlie@jyarborough.com from comment #7)

Running ESR 68.3.0. It would seem that there is now an ESR 68.4.0; on the other hand, the proffered download from the popup talks about non-ESR 72.0. Hope that helps

On a web page or in the application? If on a web page could you please provide the url?

There's a pop-up recommending an update. On the pop-up is a "download" link that goes to the non-ESR 72.0.

Please open the link and copy / paste the url for the link into this bug. Thanks!

Clearing priority so this will get attention

As reported in Bug 1672525, in addition to on the doorhanger, the incorrect, non-ESR update URL also appears in about:preferences.

As reported in Bug 1720545, this incorrect URL also appears in the About dialog.

I think this will be a good ticket for onboarding our new hire. The manualURL gets set here. That URL is coming from branding. The URL needs to be changed in the mozilla-esr91 branch, or it needs to be made ESR-aware in mozilla-central and the other branches. I'm not sure which is preferred: the latter is easy using the new MOZ_ESR flag but doesn't seem to have any precedent.

One thing to make sure to pay attention to here: localization. For example, app.update.url.manual on my machine is https://www.mozilla.org/%LOCALE%/firefox/nightly/. We need to make sure that the URL that we use for the ESR can be properly localized, probably using that same %LOCALE% variable. At a glance, it looks like the appropriate URL might be something like https://www.mozilla.org/%LOCALE%/firefox/enterprise/, but we should probably check with someone that this will work properly with the many locales that could potentially be used here.

We ultimately need to ensure two things here. First, the download page should be in the correct language. Second, the download should be in the correct language. As we move towards reliance on langpacks, that second point may become less important. But, as things stand, if someone is updating a localized repack, they probably want to update it to another localized repack.

Depends on D134085

To answer my own question, yes.

Would this fix this as well?

app.update.url.manual should be updated for ESR branches
https://bugzilla.mozilla.org/show_bug.cgi?id=1499216

https://hg.mozilla.org/mozilla-central/rev/b3e23657859c

Comment on attachment 9255822 [details]
Bug 1592731 - Update Firefox ESR's update failure doorhanger to direct user to the ESR download page. r=nalexander

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: ESR only patch
• User impact if declined: When a download of Firefox fails, you are directed to the release version
• Fix Landed on Version: 97
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): ESR only. well defined

Note: https://bugzilla.mozilla.org/show_bug.cgi?id=1747293 has a paired esr uplift that will need to land with this.

Comment on attachment 9255822 [details]
Bug 1592731 - Update Firefox ESR's update failure doorhanger to direct user to the ESR download page. r=nalexander

Approved for 91.6esr.

https://hg.mozilla.org/releases/mozilla-esr91/rev/38a8dc19e099

I've reproduced the initial issue using older esr build 68.9.0esr, failed download pages redirects to release and what's new from download failed dropdown redirected to release build notes and prefs have the incorrect values:

• app.update.url.manual is set to https://www.mozilla.org/%LOCALE%/firefox/
• app.update.url.details is set to https://www.mozilla.org/%LOCALE%/firefox/notes

Verified that using latest esr build 91.6.0esr across platforms (Windows 10, Ubuntu 18.04 and macOS 11.6), both the download failed and notes link redirect to the correct ESR pages (doorhanger, about:preferences and about dialog) and prefs have the correct values:

• app.update.url.manual is set to https://www.mozilla.org/%LOCALE%/firefox/enterprise?reason=manual-update
• app.update.url.details is set to https://www.mozilla.org/%LOCALE%/firefox/organizations/notes