Closed Bug 1436457 Opened 2 years ago Closed 6 months ago
Provide a way to remove the check for updates button in about
47 bytes, text/x-phabricator-request
|Details | Review|
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?
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.
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.
(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®exp=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.
> 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.
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.
What is app.update.channel set to in the Snap?
(In reply to Mike Kaply [:mkaply] from comment #8) > What is app.update.channel set to in the Snap? app.update.channel = release
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++?
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?
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.
We talked about this a bit via email. This function  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.  https://searchfox.org/mozilla-central/rev/f2028b4c38bff2a50ed6aa1763f6dc5ee62b0cc4/toolkit/mozapps/update/nsUpdateService.js#2462
> 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.
Could this request also be similar to bug 1508726?
Pushed by email@example.com: 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
You need to log in before you can comment on or make changes to this bug.