1524830 - Mozilla's aus servers push incompatible widevine version to 60.5.0esr

Status: RESOLVED INVALID

(Core :: Audio/Video: GMP, defect, P2)

Description

[Charlemagne Lasse]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.53 Safari/537.36

Steps to reproduce:

Install Firefox 60.5.0esr on Debian stretch (from their security repository), enabled DRM, go to https://bitmovin.com/demos/drm and start to load and play the DRM protected video on there. A yellow status message was shown that the module for DRM will be installed and I should try again. So I repeated the loading of page + selecting the DRM video a couple of times + restarted the browser

I've also downloaded the current mozilla aur xml file from https://aus5.mozilla.org/update/3/GMP/60.5.0/xxx/Linux_x86_64-gcc3/null/default/xxx/default/default/update.xml to check what widevine version was download

Actual results:

The video never played and version 1.4.8.1008 was only downloaded to the gmp-widevinecdm folder of firefox

The update.xml also showed 1.4.8.1008 as recommended version for widevine. But this version is not compatible with 60.5.0esr. The internal version number specified in the source code of firefox 60.5.0esr for widevine is 4.10.1196.0.

Expected results:

Video should play after the correct version (4.10.1196.0 or better+still compatible) of widevine was downloaded and loaded.

This can only be fixed on the aus5.mozilla.org (and similar) servers and affects all users which use the media.gmp-manager to automatically download/update these components.

Comment 1

[Julien Cristau [:jcristau]]

IIRC the debian builds have update channel set to "default" not "esr". cc glandium to see if this is something we can fix there.

Comment 3

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

(In reply to Julien Cristau [:jcristau] from comment #1)

IIRC the debian builds have update channel set to "default" not "esr". cc glandium to see if this is something we can fix there.

That would do it. We should also be able to mitigate this specific case by updating the rules without breaking non-esr 60 releases. I'll see what can be done there.

Comment 4

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

My proposed changes in Bug 1525019 should mitigate this if they go ahead. That said, using the esr channel is the proper fix here.

Comment 5

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

I believe this can be worked around locally in the mean time by opening your Firefox install location (not your profile dir) and opening <install location>/defaults/pref/channel-prefs.js and changing the line:

pref("app.update.channel", "default");

to

pref("app.update.channel", "esr");

Comment 6

[Charlemagne Lasse]

The problem of the wrong MOZ_UPDATE_CHANNEL was also reported to downstream (Debian) in https://bugs.debian.org/921381

What is the correct way to set this variable during the build? I didn't spot anything in https://salsa.debian.org/mozilla-team/firefox/blob/esr60/master/debian/rules so I would assume it is not set - and the upstream build scripts from firefox-esr just use "default" in this case

Comment 7

[Gingerbread Man]

Also reported to Gentoo, though Bugzilla doesn't allow that link in the See Also field (bug 1526992).
https://bugs.gentoo.org/677722

Comment 9

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Bug 1525019 has been resolved with changes that should now be mitigating this, but to reiterate, using the correct channel is the better/correct way for this to be handled.

Comment 10

[Charlemagne Lasse]

Thanks, but I've clicked on the link I've provided and it is still showing 1.4.9.1088. And my Debian stretch firefox-esr also downloads the old version.

Does it take more time until it is on production?

Comment 11

[Charlemagne Lasse]

Btw. gentoo fixed the problem with a similar patch to my proposed Debian one. I just hope that Debian will soon also fix the update-channel in their build.

Comment 12

[Charlemagne Lasse]

(In reply to Charlemagne Lasse from comment #10)

Thanks, but I've clicked on the link I've provided and it is still showing 1.4.9.1088. And my Debian stretch firefox-esr also downloads the old version.

Does it take more time until it is on production?

Please ignore this comment. 1.4.8.1008 was replaced with 1.4.9.1088 (which is working with firefox 60.5.0esr). So I was just blind/ignorant.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

Is there anything left to do here?

Comment 14

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Not on our end. This is mitigated by bug 1525019, and the any remaining work is downstream with distros ensuring they set the update channel correctly for ESR builds. For the bugs linked here it looks like this should be fixed in both Debian and Gentoo.