1672525 - ESR version tells user to replace with normal/rapid release

Status: RESOLVED INCOMPLETE

(Firefox :: Enterprise Policies, defect)

Description

[wearyofallthiscrap]

Attachment: The Options screen

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

My employer's IT department deployed Firefox on the ESR channel. As expected, from time to time there would be a minor update, detectable only when we were connected to the company VPN. The rest of the time, an unprivileged user could go into Options and click "check for updates" but nothing would be found. All of this is as expected.

Sometime in the 78.x series, Firefox has been popping up alerts every day that it can't find updates, and instead we should go download an entirely new install from https://www.mozilla.org/en-US/firefox/. (Since unprivileged users can't install new software, this would be a waste of time.)

While we're connected to the company VPN, we can't even force a recheck for a deployed ESR update, as the "check for updates" button is disabled once the "go to our website" blurb replaces the accompanying text -- and does not ever get enabled, until the process is killed and the browser is restarted.

I should note that, when there is a deployed ESR update, if we get on the VPN and manually click "check for updates" (before it screws itself up), it performs properly: the new ESR version is downloaded and installed correctly. A week or so later, however, the idiotic "go get the rapid release channel normal version that you can't actually install" alerts resume.

Actual results:

See attached screenshot.

Expected results:

For an ESR version, deployed by enterprise IT and centralized management, it should not be complaining about failure to check for updates. It should not be permanently disabling the "check for updates" button for the rest of the runtime session. It should certainly not be telling users to go download a non-ESR version and install it themselves.

Comment 1

[Marcela (Please NI request to Brindusa Tot)]

I will set a component to have a starting point of this. If this is not the right component please feel free to route this ticket to the corresponding team, thanks!

Comment 2

[Robin Steuber (she/her) [:bytesized]]

There seem to be two reported problems here:

1. The update failure message for ESR is giving users the download link for non-ESR Firefox.
2. Firefox is checking for updates in an enterprise environment where it should not be checking for updates.

The first problem is a known issue that we have a bug on file for: Bug 1592731. Therefore, I'm going to focus on the second problem.

(In reply to wearyofallthiscrap from comment #0)

Expected results:
For an ESR version, deployed by enterprise IT and centralized management, it should not be complaining about failure to check for updates. It should not be permanently disabling the "check for updates" button for the rest of the runtime session. It should certainly not be telling users to go download a non-ESR version and install it themselves.

You mention a number of things that you would like Firefox not to do. But you don't mention how you would like update to work. In general, this sort of thing is generally meant to be solved with Enterprise Policies, so I'm going to move this bug to that component. More information about Enterprise Policies is available here and here.

Here are some policies that you might be interested in:

• AppUpdateURL - Change the URL that Firefox uses to check for updates. Allows you to host your own update server and control what updates are installed and when.
• DisableAppUpdate - Prevent Firefox from ever updating while this policy is active.
• Bug 1653430 - We are in the process of considering a policy that would disable automatic update checks, but would allow manual update checks.

Comment 3

[Mike Kaply [:mkaply]]

Can you to about:policies and see if any values are set for AppUpdateURL or DisableAppUpdate?

Comment 4

[wearyofallthiscrap]

(In reply to Mike Kaply [:mkaply] from comment #3)

Can you to about:policies and see if any values are set for AppUpdateURL or DisableAppUpdate?

DisableAppUpdate is false.

There is no entry shown for AppUpdateURL. Presumably that's contributing to the problem?

Given that updates from a central enterprise source do already work when a new version actually is present, I'm guessing that somewhere they're already pointing to some kind of update server/repo, even if I can't see mention of it on this screen or Options. (The browser has got to find the enterprise server somehow, after all.) Possibly IT should be making that explicit with AppUpdateURL? If that would solve this, I'm all for it.

(Their Authentication and Homepage entries point to various internal domains/URLs, so they're not all left to default settings.)

Comment 5

[Mike Kaply [:mkaply]]

It sounds like they might be blocking updates somehow at the VPN level which is creating the issue. So Firefox is getting a bad update URL.

If you're willing to help us debug, you can set the preference app.update.log to try in about:config and when the update fails, bring up the JS console (Ctrl+Shift+J on Windows) and it should have lots of messages that begin with:

AUS:SVC

having those would tell us exactly what the error was.

Comment 6

[wearyofallthiscrap]

(In reply to Kirk Steuber (he/him) [:bytesized] from comment #2)

But you don't mention how you would like update to work.

I would like it to be the opposite of all the things I wrote about what's wrong: the "check for updates" should remain enabled, and the automatic checking (if enabled) should quietly fail if it can't contact the enterprise server (say, when it's not on a VPN).

I suspect that fixing Bug 1592731 would help, but being directed to download the ESR version isn't much of an improvement when the user can't do the installation in the first place. I realize FF can't "know" the user's permission set, but a decent approximation would be: if Options would show the "Your browser is being managed by your organization." banner, then the user likely can't usurp that management and shouldn't be pestered by little popups.

Comment 7

[wearyofallthiscrap]

(In reply to Mike Kaply [:mkaply] from comment #5)

It sounds like they might be blocking updates somehow at the VPN level which is creating the issue. So Firefox is getting a bad update URL.

If you're willing to help us debug

Will do, thank you! It will be a few days before I get the opportunity. If the log is more than a dozen lines or so, I'll attach it as a file.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:mkaply, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 9

[Mike Kaply [:mkaply]]

And updates?

Comment 10

[wearyofallthiscrap]

Attachment: requested AUS:SVC capture

Comment 11

[wearyofallthiscrap]

(In reply to Mike Kaply [:mkaply] from comment #5)

Recovering from surgery took longer than expected. :-) The AUS:SVC lines are captured in a new attachment above. The only things that resemble errors appear (to my layman's eyes) to be the unprivileged write access probes into the installation folder, so not really an "error".

It does seem to be trying to look for updates from the mozilla servers rather than from any corporate intranet server. (I don't know what that would look like when an update is actually present, though.) After triggering what's captured in that log, the about:preferences 'check for updates' is disabled, and the "get yer updates at mozilla.org" message is shown there.

Having the IT dept set AppUpdateURL to... something local, however they have it organized... does seem like the right thing here, perhaps combined with comment 6 fixes.

Comment 12

[Mike Kaply [:mkaply]]

Kirk: any ideas on that log?

Comment 13

[Robin Steuber (she/her) [:bytesized]]

The log seems to contradict the summary of this bug. The log indicates that an update is available, but Firefox has no way to install it. But the summary says that updates are installed when they are available.

So perhaps Firefox is prompting for a manual update because automatic update really has been broken somehow.

@weary - In order to investigate further, I need to know how you expect the update to be installed so I can look into why that isn't working. Firefox has three possible installation mechanisms on Windows:

• Update by directly writing to the installation directory. This requires that the current user be able to write to the installation directory without privilege elevation.
• Update by UAC (user account control) prompt. This means that when Firefox launches and attempts to install an update, the user will have to accept a prompt that asks if Firefox can make changes to your computer. If the current user is not an administrator, the prompt will also require an administrator's credentials.
• Update by Mozilla Maintenance Service. This requires that the Service be installed (which the Firefox installer will do by default, but it has an option not to install it). The Maintenance Service allows us to elevate the installer's privileges so that no UAC prompt is needed to elevate. This allows the updater to write to the installation directory, even if the current user lacks the privileges to do so.

Which of these mechanisms do you expect to be used when updates are installed?

Comment 14

[wearyofallthiscrap]

(In reply to Kirk Steuber (he/him) [:bytesized] from comment #13)

Which of these mechanisms do you expect to be used when updates are installed?

Firefox is installed via SCCM / "Software Center" on this network, and the users do not need administrative credentials to install or update. I presume it's the third option, maintenance service, that would be periodically telling us to go download a fresh copy from mozilla.org, but saying that I "expect" such would be too strong a word. I only see the end result of popups on ESR saying to go to mozilla.org for a fresh copy; I can't guess how it's getting there.

Comment 15

[wearyofallthiscrap]

Attachment: After earlier update to 78.6 ESR

For what it's worth: after the initial report, the 78.6 ESR update went live and was successfully applied. (I'm not sure when, because clicking "show update history" pops up an empty window with the note "no updates have been applied".) Even after updating via ESR channels, the options screen still points to the non-ESR download site, with a disabled check button.

The attached screenshot is from just after a reboot, if that factors in at all.

Comment 16

[Robin Steuber (she/her) [:bytesized]]

(In reply to wearyofallthiscrap from comment #15)

clicking "show update history" pops up an empty window with the note "no updates have been applied".)

Are you sure that Firefox is applying the updates? Perhaps your employer's IT department is deploying Firefox updates another way, such as using Windows remote management tools? That would explain why your update history is empty and updates seem to be installed despite your log saying unable to apply updates.

Comment 17

[Robin Steuber (she/her) [:bytesized]]

This bug hasn't seen any activity in almost a month. Are you still experiencing the issue? Can you provide answers for the questions in Comment 16?

Comment 18

[Robin Steuber (she/her) [:bytesized]]

Closing due to inactivity. Feel free to reopen if you are still experiencing the problem.

Comment 19

[wearyofallthiscrap]

Yes, I am still experiencing the bug. It happened today, by coincidence. I do not have privileges to change the bug status.

Enterprise-controlled Firefox (as in "your browser is being managed by your organization" warnings in Options) still should not be pointing unprivileged accounts running ESR to go download the standard versions themselves.

Comment 20

[Robin Steuber (she/her) [:bytesized]]

(In reply to wearyofallthiscrap from comment #19)

Enterprise-controlled Firefox (as in "your browser is being managed by your organization" warnings in Options) still should not be pointing unprivileged accounts running ESR to go download the standard versions themselves.

To be clear, we consider it a bug that ESR versions of Firefox, on update failure, tell the user to download the non-ESR version (Bug 1592731). But we do not consider it to be a bug that we tell the user to reinstall Firefox. That is the expected behavior when Firefox fails to update repeatedly.

If it is expected that you will not update Firefox in your enterprise environment, the DisableAppUpdate policy ought to be set to prevent Firefox from trying to update in the first place. If it is expected that you will update Firefox in your enterprise environment, then Firefox's update URL ought to be accessible so that it can update.

If more complex update logic is needed, AppUpdateURL allows for updates to be controlled by a server.

If you are expecting Firefox Application Update to work and it isn't, I can help look into that issue. The next step would be for you to answer the question in Comment 16.
On the other hand, if you are expecting that ESR Firefox will repeatedly fail to update without telling you about it, then I'm afraid that there is not much more that I can do for you. This is the expected behavior. I can give you advice for how to configure your enterprise environment so that this won't happen, but we won't be removing or disabling the feature.

Comment 21

[Robin Steuber (she/her) [:bytesized]]

Closing due to inactivity.

Comment 22

[wearyofallthiscrap]

Was offline due to tornado. Clearing needinfo flag. No point.