For everyone reading this later: The official Firefox flatpak by Mozilla on Flathub does have these codecs built-in:
2 Likes
But Layered-based official Firefox rpm by Fedora still needs it.
Exactly.
My solution was to disable the bundled Firefox and install the Flathub version…
That’s the only way to avoid 3rd party repositories.
I really hope Fedora can somehow solve the problem with ffmpeg and why it can’t be integrated into the OS. This one thing can make Fedora a lot easier for newcomers.
Please note there is FF Flatpak by Fedora which doesn’t seem have that problem.
What problem are you talking about?
As far as I know FF Fedora flatpak has only OpenH264 codec and it lacks proper ffmpeg codec…
Whilst the Flathub version has everything needed built in.
Maybe I’m wrong. This interests me as well.
Because I would like to use Fedoras version if the codecs are there.
There isn’t any benefit in using Fedora’s Flatpak other than avoiding an additional runtime, which may not really be an option either unless you really grab every single one of your Flatpak’s from Fedora.
org.freedesktop.Platform is used pretty much everywhere, so trying to avoid it won’t be particularly convenient.
Flathub’s Firefox is actually maintained by Mozilla themselves, whereas the one in Fedora is built and maintained by RedHat and therefore should always be lagging somewhat behind the upstream release.
Unless the Fedora build starts including system integration fixes that for one reason or another don’t get merged into Firefox upstream, there really wouldn’t be any single benefit to using it, not for end users anyway.
1 Like
Fedora’s Firefox always has some additional patches that the official Firefox doesn’t have (yet). Right now (and for some time), it has included a bunch of native Wayland support, for example. The fedora version has included some other Linux integration features before in the past too (like earlier GTK+3 support way back when). As Fedora (and Red Hat employees, such as the RH devs who work on Firefox) tries to upstream everything, it should eventually be included in the official Mozilla build one at some point.
(FWIW: Right now, I’m using the Mozilla build on Flathub for codec support and relying on XWayland instead of native Wayland support.)
1 Like
I’m well aware of the patches introduced in Fedora’s builds, however with most Wayland-related work having reached upstream by now I don’t see any reason to continue to use these, not until there’s some other useful feature being worked upon anyway.
Why are you using the X11 backend though?
Wayland support is available in the Flathub Flatpak, you just need to enable the Wayland socket and set an environmental variable until they’re done testing it and turn it on by default:
flatpak override --user --socket=wayland org.mozilla.firefox
flatpak override --user --env=MOZ_ENABLE_WAYLAND=1 org.mozilla.firefox
2 Likes
This did not work for me last week so I had to replace --user with --system.
Well, this is for per-user Flatpak installations.
I was under the assumption it differed from the installation operation and instead applied a per-user override (that would also for instance work for a system-installed Flatpak).
This doesn’t seem to be the case (?).
edit: This actually should work, just like user configs etc take precedence over global stuff.
I actually just verified this.
Oh, I guess I am using Wayland in Firefox from Flathub.
After going to about:support, I see “Window Protocol: wayland”.
I assumed it was XWayland because I see black window trails when resizing. When I was using non-Mozilla Wayland builds previously, it didn’t have those artifacts. (But did with XWayland.) 
The bug in question has been fixed in GNOME 3.36, however it wasn’t just a window trail but a black flicker of the whole composite area, including the shadows. Firefox sometimes leaves a black trail even on XWayland before it resizes.
FWIW: I’m on GNOME 3.36.2 and still seeing this bug.
Do you mean it was very recently fixed?
I do have a pending update to gnome-shell from the past few days (according to rpm-ostree). Last time I did a rpm-ostree update && systemctl reboot was around the middle of last week.
I’m very familiar with this bug too. Got a 1920x1200 monitor connected to a laptop with a 3200x1800 screen and using the monitor (e.g. secondary screen) only since dual screen with vastly different resolutions is not exactly seamless on Wayland and with Electron apps. Maximized Firefox usually is not sized properly after unlocking, especially when restoring from hibernation. It’s an issue that has been around for years and I’ve grown accustomed to Win+ArrowDown and Win+ArrowUp Firefox to force a resize. As far as I know it’s resize issue is still around, even though the black window pane issue might be gone.