Bug 2250527
| Summary: | H.264 WebRTC not working on Firefox under a specific (but not so unusual) set of conditions | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | NoisyCoil <noisycoil> |
| Component: | openh264 | Assignee: | Kalev Lember <klember> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 39 | CC: | klember, wtaymans |
| Target Milestone: | --- | Keywords: | Desktop |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | openh264-2.4.0-2.fc40 openh264-2.6.0-1.fc43 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2024-02-06 20:50:21 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 2250529 | ||
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/gmpopenh264.sh won't fix the issue.
Thanks for filing the issue! I think I'd prefer to add a new script for fish and keep the existing setup as is. /etc/environment.d seems promising, but nothing in the default install seems to make any use of it, and without fully understanding the implications, I'd rather not be the first with openh264 :) I wonder if you could do a PR for https://src.fedoraproject.org/rpms/openh264 and add /usr/share/fish/vendor_conf.d/gmpopenh264.fish that does the same as /etc/profile.d/gmpopenh264.sh? I can see flatpak.fish and vim-default-editor.fish already in that directory on my system and I suspect this is the right place to put system installed fish scripts. Thank you for your reply. I can certainly do a PR with what you asked (I've already written and tested the relevant file). However, the approach you suggest will not solve the issue, as I'm sure you'll recognize. A quick search suggests that there are at least 3 or 4 more shells supported by Fedora with which the problem would persist, namely: - csh from the tsch package, which reads init files from /etc/profile.d/*.csh - xonsh reads them from /etc/xonsh/rc.d - rc reads /etc/inputrc - oil reads /etc/inputrc, but when installed it does not get added to /etc/shells (so while being supported as a shell we can't really say this is supported as a *login* shell) I tested each of these as default user shells (except for oil, see the comment above) and MOZ_GMP_PATH does not get set for any of them at login. Also, this list is not exhaustive, and I didn't even attempt testing widespread shells which I could not find in the Fedora repos. The approach you suggest would require you maintainers to then chase every single login shell that's out there (certainly those which are supported by Fedora) and add appropriate additional initialization files to the system. Thus, while I am willing to submit the PR for the fish shell, I think if it gets accepted this issue should still not be marked as closed. I fully understand your position (and you're certainly not alone in this, just looking at what's in /etc/profile.d which should not be there), but in that case perhaps it's better to leave this unsolved for the general case, so that users can recognize this as a known issue. Thanks! Sure, if you want to leave the ticket open, fine with me. Maybe someone else comes along in the future and helps fix it for the other shells :) Done. While rebuilding the package for testing, I came across a build bug in the spec file (introduced in the last commit), so I'm submitting that also. I'll document what that is in the PR comment. Thanks a lot! I merged both PRs. As for rolling out the builds, there's a bit of process for sending the rpms to Cisco for hosting, so I was thinking of waiting a bit and piggybacking on the the openh264 2.4.0 release that should be imminent before sending the rpms to Cisco. No problem! FYI, the widevine-installer package is now using /usr/lib/environment.d to set MOZ_GMP_PATH. I had filed a twin bug report with them (https://bugzilla.redhat.com/show_bug.cgi?id=2250529) just moments after this one. Yep, I've been in contact with Davide and he's going to propose a Fedora Change for this - I'd like to wait for that before updating openh264 to use it just so that the change can get some wider community scrutiny. It could be that we are missing something :) In any case, I personally think it makes a lot of sense to start using /usr/lib/environment.d, I'm just being cautious here. That's great news! As mentioned before, I fully understand your position. Let's hope the community goes along with this :-) OK, openh264-2.4.0-2.fc40 is now available in the Cisco repo and contains both of your PRs. FEDORA-2025-9a54eec1fe (openh264-2.6.0-1.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-9a54eec1fe FEDORA-2025-9a54eec1fe (openh264-2.6.0-1.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report. |
The path where Firefox searches for media plugins is specified by the MOZ_GMP_PATH environment variable. mozilla-openh264 sets this environment variable by making use of a profile file, /etc/profile.d/gmpopenh264.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 OpenH264 plugin is never loaded as it is not found on the system. For example, H.264 WebRTC does not work on 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 the test with strace -f firefox 2>&1 | grep openh264 and comparing the output with one obtained when bash is the default shell. In the former case, Firefox is clearly not looking for libgmpopenh264.so in /usr/lib64/mozilla/plugins/gmp-gmpopenh264/system-installed, and the test fails. In the latter it clearly is and the test passes, as it should happen when MOZ_GMP_PATH is set correctly. I should mention that non-WebRTC H.264 of course still works in Firefox under this set of conditions, since the openh264 package (as opposed to mozilla-openh264) is enough to make that work, and, in particular, correctly setting the MOZ_GMP_PATH environment variable is not needed. To solve this bug in GNOME/GDM/Wayland, one could remove the /etc/profile.d/gmpopenh264.sh file from the package and add a new /etc/environment.d/gmpopenh264.conf file instead with the following content: MOZ_GMP_PATH="/usr/lib64/mozilla/plugins/gmp-gmpopenh264/system-installed" Or better still, to allow for other media plugins without conflicts, MOZ_GMP_PATH="$MOZ_GMP_PATH${MOZ_GMP_PATH:+:}/usr/lib64/mozilla/plugins/gmp-gmpopenh264/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 mozilla-openh264 fish 2. chsh -s /usr/bin/fish 3. Reboot/re-login 4. Open Firefox and run the test on https://mozilla.github.io/webrtc-landing/pc_test.html, as indicated on https://docs.fedoraproject.org/en-US/quick-docs/openh264/ (Check "Require H.264 video" and then "Start!"). Make sure you have a working webcam Actual Results: The image from the webcam is shown only on the right side, indicating that H.264 WebRTC is not working. Expected Results: The image from the webcam should be shown both on the right and on the left, indicating that H.264 WebRTC is working.