1436457 - Provide a way to remove the check for updates button in about

Status: RESOLVED FIXED

(Firefox :: General, enhancement, P3)

Description

[Mike Kaply [:mkaply]]

As we're creating more standalone Firefox packages that update from other locations (Snap, Flatpak), we need a way to remove the check for updates options in Firefox since those updates are not coming from Mozilla.

I'm also wondering if we should hide the buttons in prefs as well.

This brings up an interesting question, though. What happens when you try to send a system add-on to a Firefox that is in a Snap or Flatpak?

Comment 2

[Mike Kaply [:mkaply]]

This is going to move higher in priority as we move towards supporting more packaging formats on Linux (Snap and Flatpak) and maybe even Windows and Mac someday.

We need to provide some sort of mechanism to allow for different messaging on the about dialog like "Updates for Firefox are being managed externally" and removing the preference UI since it will be non functionial.

Currently locking the update preference modifies the about UI, but it is primarily aimed at enterprise.

If we decide to use a preference that can be flipped easily, we should probably make it Linux specific at first to avoid having it used incorrectly on other platforms.

Or worst case, we can detect the various package formats on the fly.

Comment 3

[Mike Kaply [:mkaply]]

OK, here's a thought. What if we simply detect the lack of app.update.channel and in those cases, don't do any update stuff?

It looks like some distros just remove channel-prefs.js anyway so app.update.channel isn't there.

This seems like a really obvious way to do it.

The other question then is how do we have an update button so that we can invoke the packages update mechamism. I have no idea on that.

Comment 4

[Jan Beich]

(In reply to Mike Kaply [:mkaply] from comment #3)
> OK, here's a thought. What if we simply detect the lack of app.update.channel and in those cases, don't do any update stuff?

app.update.channel is always defined, even if --enable-update-channel=<channel> isn't specified in .mozconfig.

https://searchfox.org/mozilla-central/rev/78dbe34925f0/build/moz.configure/init.configure#1065
https://searchfox.org/mozilla-central/search?q=MOZ_UPDATE_CHANNEL.*default&regexp=true

> It looks like some distros just remove channel-prefs.js anyway so app.update.channel isn't there.

As a workaround. Another option is to pass --disable-updater.

Comment 5

[Mike Kaply [:mkaply]]

> app.update.channel is always defined, even if --enable-update-channel=<channel> isn't specified in .mozconfig.

Not in my testing. I removed channel-prefs.js and went to about:config and there was no app.update.channel.

We do have an internal channel that we can check, but the pref is not set.

> As a workaround. Another option is to pass --disable-updater.

That's what we're trying to avoid. We want to do this at runtime.

Comment 7

[Olivier Tilloy]

I can give this a shot for the snap package. It sounds like app.update.channel is an option to explore, I'll play with that. Suggestions welcome.

Comment 8

[Mike Kaply [:mkaply]]

What is app.update.channel set to in the Snap?

Comment 9

[Ken VanDine]

(In reply to Mike Kaply [:mkaply] from comment #8)
> What is app.update.channel set to in the Snap?

app.update.channel = release

Comment 10

[Mike Kaply [:mkaply]]

I think we're going to need a generic way to know that Firefox is in a situation where it gets updates outside of Firefox. This will be for Snaps and Flatpaks.

Right now, do we have a JS way to detect the Snap or just in C++?

Comment 11

[Mike Kaply [:mkaply]]

Flatpak has this info:

https://bugzilla.mozilla.org/show_bug.cgi?id=1441922#c38

I think we'll want some feedback from Kirk on the right way to do this.

Kirk:

Goal here is to basically have the update features disabled at runtime if we detect we are a Snap or Flatpak.

At some point in the future, we might hookup the update checks to do the native stuff. Thoughts?

Comment 12

[Mike Kaply [:mkaply]]

To be more specific as to the problem with the current Snap experience:

> When a new version of Firefox is available the message in Firefox pops up to prompt the user to upgrade, but that upgrade process is governed by the snap now.  Having the ability to mute that notification at runtime might work, or have Firefox know that it's running under a managed packaging format and not show them.

Comment 13

[Robin Steuber (they/them) [:bytesized]]

We talked about this a bit via email. This function [1] is sort of the off switch for update, so that is probably where I would start. However, I think that the mechanism for this really ought to receive a security review before going too far. I am concerned about implementing features that make it easier for bad actors to disable Firefox update and I don't really understand the conditions under which we would be disabling update.

[1] https://searchfox.org/mozilla-central/rev/f2028b4c38bff2a50ed6aa1763f6dc5ee62b0cc4/toolkit/mozapps/update/nsUpdateService.js#2462

Comment 14

[Mike Kaply [:mkaply]]

> I don't really understand the conditions under which we would be disabling update.

These Firefox versions can't be updated via our standard update mechanisms. They are updated in other ways.

So anything we show in the standard Firefox (dialogs, buttons, etc) just doesn't work.

Comment 15

[Chris AtLee [:catlee]]

Could this request also be similar to bug 1508726?

Comment 17

[Olivier Tilloy]

Attachment: Bug 1436457 - Add a group policy file to disable app updates, as those are handled by snapd.

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3b8444793f55
Add a group policy file to disable app updates, as those are handled by snapd. r=jlorenzo,mkaply

Comment 19

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/3b8444793f55

Comment 20

[Johan Lorenzo [:jlorenzo]]

Landed on beta because we don't ship any mozilla-central snap, yet.

https://hg.mozilla.org/releases/mozilla-beta/rev/9772de93a464abbd57d123fa8b6addfe7474c3fa