Bug 2250529 - Widevine not working on Firefox under a specific (but not so unusual) set of conditions [NEEDINFO]
Summary: Widevine not working on Firefox under a specific (but not so unusual) set of ...
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: widevine-installer
Version: 39
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Davide Cavalca
QA Contact:
URL:
Whiteboard:
Depends On: 2250527
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-11-19 13:37 UTC by NoisyCoil
Modified: 2024-03-11 16:16 UTC (History)
4 users (show)

Fixed In Version: widevine-installer-0^20231031git8fa12dd-2.fc40 widevine-installer-0^20231031git8fa12dd-2.fc39 widevine-installer-0^20231031git8fa12dd-2.fc38 widevine-installer-0^20231031git8fa12dd-3.fc40
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-12-16 10:15:10 UTC
Type: ---
Embargoed:
noisycoil: needinfo? (kalev)
noisycoil: needinfo? (marcan)


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github AsahiLinux widevine-installer pull 5 0 None open Use environment.d instead of the bash profile 2023-11-28 18:36:51 UTC

Description NoisyCoil 2023-11-19 13:37:25 UTC
Disclaimer: I will be copying a large part of what follows almost word-by-word from https://bugzilla.redhat.com/show_bug.cgi?id=2250527, as this is basically the same bug.


The path where Firefox searches for media plugins is specified by the MOZ_GMP_PATH environment variable. For arm64 systems, widevine-installer sets this environment variable by making use of a profile file, /etc/profile.d/gmpwidevine.sh. GDM is known not to source those files directly when logging into gnome-wayland sessions (see references below). Instead, as I understand it, gnome-session passes them to the user's default shell, which is then responsible for re-exporting them.

As a result, when the DE uses the user's default shell to source /etc/profile.d/*, and if the user's default shell does not understand the `export` command (or variable assignment in the form VAR=VALUE), the MOZ_GMP_PATH environment variable is never set, and the Widevine plugin is never loaded as it is not found on the system. For example, Spotify does not work on arm64 Fedora Workstation's Firefox if the user has fish as its default shell. This can be checked as detailed in the "Steps to Reproduce". That the path is not being set correctly in this situation can be checked by stracing the Firefox session that runs Spotify with

strace -f firefox 2>&1 | grep widevine

and comparing the output with one obtained when bash is the default shell. In the former case, Firefox is clearly not looking for libwidevinecmd.so in /var/lib/widevine/gmp-widevinecdm/system-installed, and Spotify doesn't work. In the latter it clearly is and Spotify works, as it should happen when MOZ_GMP_PATH is set correctly.


To solve this bug in GNOME/GDM/Wayland, one could remove the /etc/profile.d/gmpwidevine.sh file from the package and add a new /etc/environment.d/gmpwidevine.conf file instead with the following content:


MOZ_GMP_PATH="$MOZ_GMP_PATH${MOZ_GMP_PATH:+:}/var/lib/widevine/gmp-widevinecdm/system-installed"


This way, MOZ_GMP_PATH will be caught by systemd during the init phase and then re-exported to GDM and to gnome-wayland sessions, without being filtered by the user's default shell. I can confirm that this fixes the issue on GNOME/GDM/Wayland, but I didn't test what happens with other DMs/DEs/X11, etc.


*** Note ***

- /etc/environment{,.d/*} are sourced by systemd, so any changes to those files require either a full reboot or killing the systemd user session to enter into effect. A re-login is not sufficient.


*** GNOME/GDM/Wayland /etc/profile behavior references ***

- https://bugzilla.gnome.org/show_bug.cgi?id=736660 (GNOME/GDM/Wayland do not source profile files directly. This was solved by wrapping gnome-wayland sessions within the user's default shell, see below)
- https://github.com/swaywm/sway/issues/3109 (as above, but in sway)
- https://gitlab.gnome.org/GNOME/gnome-session/-/commit/5e36cd63e71520f829bbd77c102b64179e08992a (the fix introduced to work around GNOME/GDM/Wayland not sourcing profile files directly: wrap GNOME Wayland sessions around the user's default shell)

Reproducible: Always

Steps to Reproduce:
1. sudo dnf install widevine-installer fish
2. sudo widevine-installer
3. chsh -s /usr/bin/fish
4. Reboot/re-login
5. Try to listen to music on Spotify
Actual Results:  
Spotify doesn't work.

Expected Results:  
Spotify should work.

Other services that require Widevine, such as Amazon Prime, don't work either.

Comment 1 NoisyCoil 2023-11-19 14:46:05 UTC
As an afterthought, I think the reason why the plugin is not working when the user's default shell is the fish shell is not just because fish does not understand VAR=VALUE assignments and the `export` command, but even more basically because it just isn't reading /etc/profile{,.d/*} when it is invoked as a login shell. To see this, run

strace -e trace=openat fish -l 2>&1 | grep etc

and compare the output to that of

strace -e trace=openat bash -l 2>&1 | grep etc

or

strace -e trace=openat zsh -l 2>&1 | grep etc

fish's analogue of /etc/profile{,.d/*} is /etc/fish/conf{ig.fish,.d/*}.

Thus, this bug can arise either when the user's default shell doesn't understand `export` and VAR=VALUE, or when it just doesn't read /etc/profile{,.d/*} when invoked as a login shell, implying that any solution based on just changing the content of /etc/profile.d/gmpwidevine.sh won't fix the issue.

Comment 2 Davide Cavalca 2023-11-28 18:36:52 UTC
After some discussion upstream I agree that environment.d is preferable here.

Comment 3 Davide Cavalca 2023-11-28 18:48:34 UTC
Put up https://src.fedoraproject.org/rpms/widevine-installer/pull-request/1 for this

Comment 4 NoisyCoil 2023-11-29 10:10:55 UTC
I've tested the PR and it works for me. I will close this bug report when it gets merged. I've left a comment with a suggestion there.

Thank you for the fix!

Comment 5 Fedora Update System 2023-11-29 23:14:04 UTC
FEDORA-2023-471cd39ea3 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2023-471cd39ea3

Comment 6 Fedora Update System 2023-11-29 23:15:46 UTC
FEDORA-2023-471cd39ea3 has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 7 Fedora Update System 2023-11-29 23:25:14 UTC
FEDORA-2023-562915c3d5 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-562915c3d5

Comment 8 Fedora Update System 2023-11-29 23:31:19 UTC
FEDORA-2023-c5c91fef19 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-c5c91fef19

Comment 9 Fedora Update System 2023-11-30 03:40:26 UTC
FEDORA-2023-c5c91fef19 has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-c5c91fef19`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-c5c91fef19

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 10 Fedora Update System 2023-11-30 04:37:24 UTC
FEDORA-2023-562915c3d5 has been pushed to the Fedora 39 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-562915c3d5`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-562915c3d5

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 11 Fedora Update System 2023-12-01 01:23:11 UTC
FEDORA-2023-562915c3d5 has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 12 Fedora Update System 2023-12-08 01:42:17 UTC
FEDORA-2023-c5c91fef19 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 13 Hector Martin 2023-12-16 10:00:06 UTC
This broke Widevine for everyone *not* using fish, because openh264 is still not fixed and their script *clobbers* the path instead of appending to it. Our original solution relied on alphabetically running *after* openh264 to work. Now we run before and get clobbered.

Reverting. We can revisit this after openh264 switches over to environment.d *and* to appending to the variable first.

Comment 14 Fedora Update System 2023-12-16 10:10:18 UTC
FEDORA-2023-d957f751a6 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2023-d957f751a6

Comment 15 Fedora Update System 2023-12-16 10:13:39 UTC
FEDORA-2023-3d6752f5ba has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-3d6752f5ba

Comment 16 Fedora Update System 2023-12-16 10:13:49 UTC
FEDORA-2023-ea1faa4a96 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-ea1faa4a96

Comment 17 Fedora Update System 2023-12-16 10:15:10 UTC
FEDORA-2023-d957f751a6 has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 18 Hector Martin 2023-12-16 10:16:39 UTC
I think the revert commit description is triggering the closes, sorry :/

Comment 19 NoisyCoil 2023-12-16 10:47:09 UTC
> This broke Widevine for everyone *not* using fish, because openh264 is still not fixed and their script *clobbers* the path instead of appending to it.

For the record, fish has nothing to do with this. mozilla-openh264 is breaking stuff by not releasing an already-merged, fish-unrelated, one-month old fix (https://src.fedoraproject.org/rpms/openh264/c/01e104cfc7e5c92e529c7c703a37b06b37d755ec?branch=rawhide) to a non-working patch that was merged 4 months ago (https://src.fedoraproject.org/rpms/openh264/c/10b5521dd013e27d25cdc30162d44b1882f8bae2?branch=rawhide). @kalev

Comment 20 Fedora Update System 2023-12-17 01:35:22 UTC
FEDORA-2023-3d6752f5ba has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 21 Fedora Update System 2023-12-17 01:42:12 UTC
FEDORA-2023-ea1faa4a96 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 22 NoisyCoil 2024-03-11 16:16:06 UTC
A new version of openh264 which does not overwrite `MOZ_GMP_PATH` has now been released.

> We can revisit this after openh264 switches over to environment.d *and* to appending to the variable first.

@marcan: they are still not using environment.d, but given the content of their profile.d file,

> if [[ ":$MOZ_GMP_PATH:" != *":/usr/lib64/mozilla/plugins/gmp-gmpopenh264/system-installed:"* ]]; then
>     MOZ_GMP_PATH="${MOZ_GMP_PATH}${MOZ_GMP_PATH:+:}/usr/lib64/mozilla/plugins/gmp-gmpopenh264/system-installed"
>     export MOZ_GMP_PATH
> fi

now it could be safe to switch to environment.d anyway.


Note You need to log in before you can comment on or make changes to this bug.