Hi my name is Oliver Propst and I have been inolved with GNOME and some ohter free and open source projects for a while.
Now while I understand that it might a complicated process it would be awesome to see “full” Chromium [1] and support for the Brave browser in future editions of Fedora Silverblue (specifically) as well as better multimedia/playback support in general.
*it seems in general btw like Fedora Silverblue these days is developed in somewhat “sporadic fashion” in different GitHub tickets (which I think makes it a little hard to track progress).
What’s full Chromium support? We have Chromium in the Fedora repos, Chromium + extended codecs support in RPM Fusion and Flathub has Chrome & Chromium as beta Flatpaks.
For the Brave browser to be available in Fedora, it would need to be packaged there and this would require it being fully open source (is it?). Otherwise you can create a Flatpak and publish it on Flathub.
What issues are you facing with multimedia/playback support?
Disclaimer: Only speaking for myself here. I don’t speak for the Silverblue team.
Fedora Silverblue issues are tracked in Issues · fedora-silverblue/issue-tracker · GitHub but work happens in other repos. The most important thing to remember is that Fedora Silverblue is Fedora, thus any changes or improvements that are added or made in Fedora will also end up in Silverblue. Silverblue is moving as fast as Fedora and the project is not known for stagnation.
I’m using Firefox on Silverblue v.35 and I don’t have good multimedia support. For example, when I am on the Twitter page, none of the videos will play.
Does this work with the rpm-ostree Firefox that Silverblue installs by default? Or just the flatpak Firefox? I’m a little unsure of the differences between the two versions.
@apollo18
Nope, it only works with the Flatpak, more specifically the official Mozilla one from Flathub which is the one you really ought to use, not the one in Fedora’s Flatpak repo.
For rpm Firefox you’re going to have to install the codecs in your system.
Widevine is DRM mostly used by streaming services. I doubt it’s in any way relevant to your Twitter video playback. Check after OpenH264 finishes installing.
About your question regarding the available versions of Firefox.
There are (primarily) 2 ways to get Firefox in Fedora. You can either get a plain .rpm system package or install a Flatpak for it.
You can technically also unpack a .tar.gz, install a Snap, use an AppImage, even install the Windows build through a gazillion ways to manage Wineprefixes, but that’s beside the point.
So back to .rpm and Flatpak. They’re both packaging formats meant to provide you with software. RPMs are traditional non-sandboxed system packages using dependencies from your system, whereas Flatpaks are generally sandboxed, to a bigger or lesser extent depending on the app and the maintainer, and make use of Flatpak runtimes and extensions instead of using deps from the host system.
Fedora builds Firefox and provides an .rpm as well as a Fedora Flatpak for it. Mozilla also provides an official Flatpak Firefox build through Flathub. The only reason why Fedora provides their own Flatpaks instead of using Flathub, besides quality control, is licensing.
Though starting with F35 (iirc) they’ve also added Flathub ootb, albeit with a filter for proprietary apps and whatnot.
There’s one reason why you might want to use the system package (rpm) and that’s if you’re using KDE Connect (same with GS Connect) or any similar Firefox plugin attempting to talk to a host package that may not always work properly inside a Flatpak at this time.
Besides that, there’s absolutely no reason why you’d take Fedora’s Firefox Flatpak over the official Mozilla one. Besides the Flathub one being the official one and the one to always receive updates first, it’s also using the Freedesktop Platform runtime, as opposed to Fedora’s Platform one, which is why freedesktop runtime extensions work with it, like the aforementioned ffmpeg codecs.
No You don’t have to do that. The flatpak is independent of the system installed version. Both can exist at the same time without interference. You may need to do some configuration of the flatpak version in order to point it at your existing user info/settings, or import them. You may want to install the Flatseal flatpak tool.
You don’t really need to uninstall the RPM version, not until you try out the Flahpak and confirm it’s working for you anyway.
Flatpak Firefox won’t have access to your previous FF profile cause the profile paths differ due to sandboxing.
You can manually copy over your profile or setup Firefox sync for whatever you need synced between them. Syncing is end2end encrypted. This means you’re also gonna have to leave both browsers running in older for the data to be synced between them.
In order to install Firefox from Flathub you’re going to need to add Flathub to your Flatpak repos first.
This ffmpeg-full differs to the one posted above as it specifies a different version for the extension.
Firefox has moved on from targeting freedesktop platform runtime 20.08 to 21.08 recently, so I doubt installing the extension meant for 20.08 would actually solve anything.
One way to confirm the runtime a Flatpak uses, among other things, is using flatpak -m info org.mozilla.firefox.
At some point Firefox is going to move on to another runtime and you’re probably going to have to install the extension again, unless some other Flatpak using it pulls it in automatically.
But that’s going to take a while as there’s no replacement coming out any time soon.
In case you don’t wish to use Firefox Sync:
Flatpak Firefox reads your profiles from here ~/.var/app/org.mozilla.firefox/.mozilla/firefox/ as opposed to unsandboxed Firefox using ~/.mozilla/firefox/.
So all you have to do is copy your profile over to the new directory and select it inside Firefox.
One way to do that is through navigating to the about:profiles page.
There’s a chance you might need to add the profile name to the profiles.ini file in that very same directory, but I haven’t done that in a while so I can’t confirm.
Unfortunately, I don’t think there’s any way to be notified of such changes besides tracking a Flatpak’s metadata one way or another.
I guess the easiest way to go about this without implementing a repo watcher service would be through monitoring installed Flatpaks using a cron job or even through a flatpak cli alias to a wrapper of sorts.
I’m no Flatpak expert by any means, but as far as I can tell sdk extensions don’t automatically install “updates” for newer runtime versions.
It would be nice if we could opt in to automatically reinstalling previously installed extensions upon pulling a new runtime.
