Let's consider performing regular GMP update checks while a session is running. The overall GMP update scheduling is non-trivial, so this bug is specifically scoped to the following case:

We will check for GMP updates after a session is started. This check is done once per session and can lead to problems in the following scenario

1. A users starts a session that already has GMPs installed. Firefox checks for GMP updates, none are found.
2. Mozilla deploys a GMP update.
3. The user continues with their same session. Until they restart that session, they will not get GMP updates and will continue with the GMPs already installed at the time of the first step.

This becomes problematic for users in very long running sessions.

I wonder if we can instead check on a regular interval even in running sessions. I'm not 100% on the best way to do this, but imagine it's not too hard. I think the bigger issue is the load we'd place on our update servers. We'd want to make sure that we don't cause issues if we're doing these checks more often.

I'm not clear if this should already be happening -- I thought we were updating without a restart, then I thought we weren't (and raised this bug), now I'm not sure. Part of the GMP update mechanism being complicated, is that it's driven by several different mechanisms. One of these is the addon update mechanism, which appears to kick off from here. If that is doing background update checks for the GMP, then we don't need to do anything here.

So note to myself, follow and verify the above code. And if it does do regular background updates, verify that it's tested (if we can).

Digging further I'm starting to think this should already be happening. So this may be a matter of checking our current logic, and if it's not doing what's expected, figuring out why.

Looking more at the addon updater logic, I think background updates from the addon updater should update Widevine. This can be tested in a running Firefox by doing the following

• Delete the media.gmp-widevinecdm.version pref, this will trigger an uninstall of Widevine.
  • You can verify that Widevine is uninstalled in about:addons under the plugins tab -- it should show that the install in now pending.
• Delete the media.gmp-manager.lastCheck pref, this will ensure that our timing checks don't prevent Widevine being updated.
• In a browser console, execute ChromeUtils.import("resource://gre/modules/AddonManager.jsm", null).AddonManagerInternal.backgroundUpdateCheck(), this will trigger the background update check, and should install Widevine.
  • This can be verified in about:addons , the install should no longer show as pending.

What I don't yet understand is how often backgroundUpdateCheck should run if I don't trigger it (and if I can verify if it's running as expected or not).

Aki confirmed that https://balrog.services.mozilla.com/rules?product=Widevine#ruleId=17590 should send it to all esr users >= 78.10.0, and https://balrog.services.mozilla.com/rules?product=Widevine#ruleId=17581 should send it to all other channels >= 90.0 so from Balrog's perspective things should be good.

The frequency of update is hardcoded in-tree so if we needed to adjust that we may be looking at different options but that's a different path to follow.