|Summary:||www-client/firefox[openh264] does not work as advertised|
|Product:||Gentoo Linux||Reporter:||Michelangelo Scopelliti <kernelpanic>|
|Component:||Current packages||Assignee:||Mozilla Gentoo Team <mozilla>|
|Package list:||Runtime testing required:||---|
Description Michelangelo Scopelliti 2021-02-22 19:19:56 UTC
According to the use description, an USE=openh264 should "Use media-libs/openh264 for H.264 support instead of downloading binary blob from Mozilla at runtime". After the installation, on a clean profile, openh264 is shown as "system installed"; nonetheless, any search for updates (addons) causes the openh264 binary blob to be donloaded and "upgraded" from 2.1.1 to 1.8.1. Currently, my workaround consists in removing the "gmp-gmpopenh264" directory and substituting it with an empty file (same name, impossible to put a file inside). This way, in about:plugins I can see a system installed openh264 (no version info, though). Removing the file gmp-gnpopenh264 causes the download (again) of openh264 1.8.1 Reproducible: Always
Comment 1 Thomas Deutschmann 2021-02-23 17:56:14 UTC
Confirmed as described.
Comment 2 Thomas Deutschmann 2021-02-23 18:59:33 UTC
OK, it's complicated: Yes, Firefox will download the blob. Although the blob version is showing up in about:plugins, Firefox will not use it. How to proof that? Start Firefox with MOZ_LOG="GMP:5" It will loop through all available versions but will use 2.1.1 from system in the end. about:support should also list MOZ_GMP_PATH=/usr/lib64/nsbrowser/plugins/gmp-gmpopenh264/system-installed So I will only update USE flag description but we will not change anything. I.e. will not apply https://src.fedoraproject.org/rpms/firefox/blob/main/f/disable-openh264-download.patch like Fedora is doing because users which already have the blob should still receive updates so they don't end up with an outdated/vulnerable version somehow when switching USE flags.
Comment 3 Michelangelo Scopelliti 2021-02-25 11:19:42 UTC
(In reply to Thomas Deutschmann from comment #2) > OK, it's complicated: > [...] Thank you for the analysis. It works as you describe. May I ask you what do you think about my workaround? Is it safe?
Comment 4 Thomas Deutschmann 2021-02-26 14:00:46 UTC
"Safe" in which context? Check with MOZ_LOG output. I guess Firefox tries to load but will skip and ignore. Of course, this behavior can change in future when Mozilla for example will decide to replace the detected non-working copy... But the worst thing which could happen is that you end up with an unused blob again. So the *safest* hack would be patching firefox like Fedora does to block the blob download at all. If they are going to change something you will also notice because the patch no longer applies.
Comment 5 Michelangelo Scopelliti 2021-02-26 14:14:38 UTC
(In reply to Thomas Deutschmann from comment #4) > "Safe" in which context? Check with MOZ_LOG output. I guess Firefox tries to > load but will skip and ignore. > "safe" in the sense of resource use, like continuous trying and failing to write to the disk -- thus also clogging the logs. I didn't see anything like that in the logs, but before this bug I'd never used MOZ_LOG. > Of course, this behavior can change in future when Mozilla for example will > decide to replace the detected non-working copy... > > But the worst thing which could happen is that you end up with an unused > blob again. So the *safest* hack would be patching firefox like Fedora does > to block the blob download at all. If they are going to change something you > will also notice because the patch no longer applies. Well, this could be safer for *me*, but your consideration in comment #2 still apply, and the safest way (for all) should still be maintaining the blob download. Thank you again for the clarification.