In bug 1799516, we intend to ship Firefox as a Debian package in a Mozilla owned APT repository. This means, Debian-based Linux distributions will get their Firefox updated by their OS package manager rather than by Firefox internal updater. We currently don't notify users so they're not reminded they have to restart Firefox.

We have the same behavior on the MSIX package (bug 1709696): the Microsoft Store updates Firefox but users keep using the old version because they're not prompted.

I'm happy to discuss details if needed 🙂

Is there a way to notify running Firefox processes there has been an update so that they will remind people to restart? On Linux, with package managers like APT, there is usually a post-install hook. Maybe we can use that to use to send some sort of signal out to the running processes?

(In reply to Gabriel Bustamante [:gabriel] from comment #1)

Is there a way to notify running Firefox processes there has been an update so that they will remind people to restart? On Linux, with package managers like APT, there is usually a post-install hook. Maybe we can use that to use to send some sort of signal out to the running processes?

There is currently no way to tie into the update notifications from outside of Firefox, but I'm sure we could add something.

For APT, we could add a postinst script that does something after the Firefox .deb is unpacked (if there is a previous version.)

How could we trigger a notification similar to the "Update available - restart now" notification on the app menu from a postinst script?

Would it call the Firefox binary? Does that notification download the update? or does it just restart Firefox?

(In reply to Gabriel Bustamante [:gabriel] from comment #3)

How could we trigger a notification similar to the "Update available - restart now" notification on the app menu from a postinst script?

The code that triggers this notification is this:

Services.obs.notifyObservers(update, "update-downloaded", update.status);

where update should be a valid nsIUpdate.

But I'm not sure how to invoke this from the postinst script. One idea is to add a Firefox command line argument that would use a remote connection to the running Firefox process (like how invoking the Firefox binary with a URL when Firefox is already running currently works) that would trigger this code. I imagine this is almost certainly possible, but I don't know the details about how to make it work. Note that one potential caveat here is that this feature presumably wouldn't work if Firefox was started with -no-remote. I believe that testing is run with this flag, so I'm not sure if there would be a viable way to add testing for this feature.

There is also another problem. The "update-downloaded" listener is only connected when Firefox is build with support for the updater. I think you could get around this by instantiating the UpdateListener module and calling its observe method directly. But UpdateListener isn't really meant to be instantiated when Firefox isn't built with update support. We would probably need to rework the module a bit to support this. My main concern is that we probably want to avoid instantiating nsIApplicationUpdateService or nsIUpdateManager in that case.

Another consideration here is that while I presume that Mozilla's Apt repository uses a copy of Firefox built without support for the updater, many other Linux repositories instead use the DisableAppUpdate Enterprise Policy. If we add this feature, we probably want to prepare for the possibility that these repositories might start using it whether we intend for them to or not. I suspect that accommodating this is probably as simple as having any checks that need to be added in UpdateListener for AppConstants.MOZ_UPDATER should probably also check for Services.policies.isAllowed("appUpdate").

Does that notification download the update? or does it just restart Firefox?

Activating the notification just restarts Firefox.

The package is build with support for the updater. There's a sentinel that signals to Firefox that it is running as a packaged app (Bug 1799503) but the build still sets MOZ_UPDATER=1 (it's the same build we distribute as a .tar.bz2 archive.)

Ah, I forgot about that. I suspect that it doesn't change much though. I think that the correct approach is probably still the same except that the check should instead be more like AppConstants.MOZ_UPDATER && !UpdateService.disabled.

Oh, OK. I think I see. We'd need to add a check like that around here to adjust the behavior when we notify the observer?

Some of the attributes in nsIUpdate make sense in the context of an APT update and could be populated using the new package data post install. It doesn't look like the UpdateListener uses data in the nsIUpdate when it shows the restart notification though.

I was looking at mozilla-central/toolkit/xre/nsAppRunner.cpp (because I see references to the command line arguments.) I can't seem to find the code that is called when Firefox is started with a URL and uses a running instance to open it. Is the AppRunner where we could add a new flag?

(In reply to Gabriel Bustamante [:gabriel] from comment #7)

Oh, OK. I think I see. We'd need to add a check like that around here to adjust the behavior when we notify the observer and the UpdateService is disabled?

Minimally, that's probably what's needed. I'm a bit nervous though about having parts of that file that are okay to call into without (useful) access to the update service and other parts that are not. It's not that big of a file. It seems likely that it's reasonable to fix up the whole thing such that it does the right thing in the !AppConstants.MOZ_UPDATER || UpdateService.disabled case. I should be able help with this, if necessary, though if this needs to be done on a particularly short timeline, I may not be available fast enough.

We probably want to make a decision early on in the process of doing this whether we are going to support the !AppConstants.MOZ_UPDATER case. I feel like it is not unreasonable to expect that Ubuntu will want to take advantage of this feature. Last I heard, they were building their own distribution that does, in fact, disable the updater. So either we should choose to support this properly, in which case we will need to make sure that UpdateListener.sys.mjs gets included in the build even when built without support for the updater (it currently is not), or we will want to gate off this entire feature if Firefox isn't built with support for the updater. I think either route is acceptable, I just don't want the feature to exist in a broken state when Firefox is built that way.

Some of the attributes in nsIUpdate make sense in the context of an APT update and could be populated using the new package data post install. It doesn't look like the UpdateListener uses data in the nsIUpdate when it shows the restart notification though.

Yeah, (from memory) little to none of that information really gets used. But the expectation there is that it be as close to a "real" nsIUpdate as possible. There has been consideration before of putting more of that information into certain prompts. So unless there is a compelling reason not to, it would be good to have it populated as thoroughly as is reasonably possible.

I was looking at mozilla-central/toolkit/xre/nsAppRunner.cpp (because I see references to the command line arguments.) I can't seem to find the code that is called when Firefox is started with a URL and uses a running instance to open it. Is the AppRunner where we could add a new flag?

Taking a quick look, my best guess is that this happens around here. But this is pretty far outside my area of expertise, so I don't really know.

Yeah, I agree, the feature should be available when the browser is built without support for the updater (if possible.)

It's not unreasonable to expect people building Firefox without the balrog update mechanism to try to use something like this to notify users when there's an update available.

I dunno if this needs to be done in a particularly short timeline, but it would be lovely to have it, no doubt.

I was looking at the Debian docs, and it seems the preinst script actually knows if a package is being upgraded or if it is a fresh install. It could leave a flag for the postinst script. I am not sure if the postinst script getting a value for most-recently-configured-version means it is an upgrade (which was my original assumption but I read somewhere that postinst might get a value for that if someone uninstalled the package and the package left some configuration behind.)

Taking a quick look, my best guess is that this happens around here. But this is pretty far outside my area of expertise, so I don't really know.

Yeah, this is not straight forward D:

Is anyone familiar with the app runner and the remote service it's using to send the url to the running process?