#21

Even though Flathub just like Fedora has massive Red Hat support, apparently Fedora policy dictates that it cannot ship with packages that are not built by Fedora itself. So in stead of throwing their weight behind Flathub the Firefox in the image can either be layered Firefox or the unofficial Firefox flatpak build from Fedora’s own Flatpak repository. Which might not be up to par and as up to date as the official one. Waste of time and resources if you as me, but apparently adding Flathub to the “whitelist” is not an option…

I was wondering the same thing. Don’t know!

Not as far as I know. But as mentioned by Vala it is indeed the official package. Has since been picked up by Phoronix, OMG Ubuntu, Linux Uprising and others.

By the way the Flatpak version does not use Wayland yet. If you are running Wayland and want Firefox to make use of it you’ll have to run these two commands to enable it for now:

flatpak override --socket=wayland org.mozilla.firefox
flatpak override --env=GDK_BACKEND=wayland org.mozilla.firefox
3 Likes
Dropping firefox from the base image
#22

But why ship with Firefox at all? Silverblue could ship with Epiphany and include a wizard-setting that allows simplified adding of Flathub (like Ubuntu’s installers used to do with mp3). This seems like a lot of duplication of effort to me.

Btw, thanks for the Wayland instructions!. Is there any downside to overriding it this way? Does it work well?

#23

They ship it with Firefox because Epiphany is a sub-par web browser (compared to FF, Chrome, Safari and Edge) and going online is about the first thing users want to do. This is about the out-of-the-box user experience and apparently important enough for Fedora to deviate from vanilla GNOME.

It works well and does not seem to have any negative side effects. In fact this will allow you to benefit from the recent graphics processing advances like GPU offloading which are mostly Wayland-only. Keep in mind though that many of them are disabled by default in 75 though, so you might need to enable some things manually inside Firefox.

Currently the official Firefox Flatpak is set up to use X11 / XWayland, I assume that will be fixed in due time. The socket permission is pretty harmless. The environment setting will break Firefox on X11 though, so only set that if you’re running Wayland. Which is the default in Fedora, for everyone except those using the proprietary NVIDIA driver if I’m not mistaken.

1 Like
#24

To be clear, I was only talking about Silverblue. It’s already not a good out of the box experience, since so many common Gnome tools are excluded and separated out into Flatpaks that you need to get from either the Fedora registry or Flathub (also, the ones from the registry are often broken, in my experience, and not just from locale issues). I’m fine with this, btw! I prefer to install the tools I need and not get a thousand games I never play installed as part of the base image.

Thanks, I’ll try the Wayland override!

#25

It worth to be mentioned here once more that Flatpak was designed to ship software directly to users from authors, skipping all the intermediate entities. So that “policy” looks outdated and out of the nowadays concept.
After all, Flatpak builds are reproducible so Fedora could just review Mozilla’s FF manifest and let it go.

1 Like
#26

I’m pretty sure you’re preaching to the choir by saying this inside the Silveblue community @bam. Most of us probably feel that way. Especially since many of the same people behind Fedora are also the people behind Flatpak and Flathub: the Red Hat engineers. A lot can even be said for this policy in fact being a risk: the Firefox Flathub builds come immediately upon product release, thanks to their build automation, while Fedora’s own RPM’s and Flatpaks are inevitably delayed until they pull it from upstream.

Anyway I don’t know who is in a position to exempt Flathub from this policy. All I know is that it isn’t me…

#27

I am fine with Firefox being in both repositories and even having the Fedora version out of the box. It is easy enough to switch repos after you do the install. I would rather have it as a Flatpak out of the box than built into the tree though. That way you could even opt to use another browser like Brave, if it is available from a Flatpak repo. I think the current Fedora policy is to ensure a consistent packaging process, but I am not sure what advantage that has in a Flatpak future.

#28

Is it possible to use the flatpak Firefox to install Gnome Extensions? I have the Gnome Shell Integration plug-in and the chrome-gnome-shell package installed but Firefox complains that “native host connector is not detected” when on the extensions.gnome.org site.

1 Like
#29

Probably not. GNOME recently launched a separate extensions application so you no longer need to use the web browser for this. It should be part of the next Fedora release.

#30

The application handles extension preferences, updates and removals, but not browsing and installing new extensions. The website is still required for those actions.

Not easily, and it looks difficult to make it easy.

That said, if you don’t mind a pile of hacks and opening up the browser sandbox a fair bit:

  1. make the connector and shell settings available to the flatpak (essentially copies chrome-gnome-shell to a location in HOME that the sandbox has access to)

    MOZDIR=$HOME/.var/app/org.mozilla.firefox/.mozilla
cd $MOZDIR
mkdir bin native-messaging-hosts schemas
cp /usr/share/glib-2.0/schemas/gschemas.compiled schemas
sed s:/usr:$MOZDIR: /usr/lib64/mozilla/native-messaging-hosts/org.gnome.chrome_gnome_shell.json > native-messaging-hosts/org.gnome.chrome_gnome_shell.json
# last chrome-gnome-shell release misses commit 3435017550b
curl https://gitlab.gnome.org/GNOME/chrome-gnome-shell/-/raw/master/connector/chrome-gnome-shell.py | sed '1c #!/usr/bin/python3' > bin/chrome-gnome-shell
chmod +x bin/chrome-gnome-shell

  2. run firefox with a different runtime (to satisfy chrome-gnome-shell dependencies) and with additional permissions

    flatpak run --runtime=org.gnome.Platform//3.36 \
    --own-name=org.gnome.ChromeGnomeShell \
    --talk-name=org.gnome.Shell \
    --env=GSETTINGS_SCHEMA_DIR=$HOME/.var/app/org.mozilla.firefox/.mozilla/schemas \
    --filesystem=xdg-run/dconf --filesystem="~/.config/dconf:ro" \
    --talk-name=ca.desrt.dconf --env=DCONF_USER_CONFIG_DIR=$HOME/.config/dconf \
    org.mozilla.firefox
1 Like
#31

Doh! So what’s the use?

GNOME keeps surprising me… Extension preferences were already part of Tweak Tool, which made absolutely no sense to me as a separate tool. Almost all of it seems suitable for integration into the control panel. Then there was the GNOME extensions, which are extremely powerful and useful but no novice user knows about them or where to find them. Installation through a website has been troublesome for ages due to browser add-on requirement. So why not make it a GNOME Software add-on?

Anyway now with browsers increasingly containerized and sandboxed it becomes completely broken. And along comes a separate extensions app (which should just be part of the control panel) which… doesn’t handle installation! I love most of the GNOME desktop experience (with some extensions) but this is just messed up…

#32

I might be mistaken, but aren’t extensions already part of GNOME Software? If you search for your required extension in Software, then it goes out to extensions.gnome.org to find it.

#33

Not to my knowledge! I believe for this purpose some popular extensions are packaged as RPM’s.

#34

Thanks @fmuellner for those excellent details on installing extensions - I may pass on this for now, you are right it’s a bit clunky.

You do wonder what direction Gnome is taking with this. We now have the extensions app - which seems to replicate mostly what already exists in the gnome-tweaks app, but is overall less useful. And still the only friendly way to install new (non-rpm based) extensions depends on Firefox or Chrome - from memory even Gnome’s own browser Web cannot do this. In a Silverblue context especially, the Firefox flatpak makes a lot of sense and it sure would be nice to utilize it more fully without having to reply on an RPM/built-in browser in future.

#35

They used to, but the plugin was removed in 3.36.

Trying to deal with all kinds of installable-things-that-aren’t-apps turned out to be quite a strain on the code base, so the developers decided to focus on the main use case.

I must say that it was quite the bummer to find out just how incompatible the whole browser integration is with sandboxing. It looks like we’ll have to bite the bullet and think about implementing installation support in the extensions app …

Except that for showing the actual extension preferences, tweak tool always launched a small helper program provided by gnome-shell. The “new” Extensions app isn’t actually that new, it’s an improved version of said helper program.

If it makes you feel better, think of it as cutting out a middle man.

(There’s also the tiny little detail that the app is actively maintained, while tweak tool has not seen a single code change since 3.34.0)

Almost all is a stretch IMHO, but some of the options are indeed being integrated into Settings.

and dangerous. Don’t get me wrong, live-patching the compositor is powerful, but it can never be as safe as - say - chosing between AM-PM and 24-hour clock format. Nothing in Settings should be able to break your entire session, which means that extension management will be kept separate.

1 Like
#36

Thanks for the insights @fmuellner!

It does! :stuck_out_tongue:

Important consideration! To that end I have never understood why the code or functionality of the 10-or-so most popular extensions are not just integrated in the main Shell code and the presented as configuration settings. Stuff like OpenWeather, Dash to Dock, Workspace to Dock, Caffeine, GSConnect, Clipboard Indicator, etc. are valuable additions, can be presented as out-of-the-box desktop preference options to users and this way you reduce the chance of of extensions breaking stuff. So why isn’t the GNOME Shell feature scope being expanded like this? Especially with distros like Ubuntu already shipping an extension like Dash to Dock by default.

1 Like
#37

Agree that UX without Dash to Dock seems strange :slight_smile:

#38

Using @fmuellner’s instructions was I was able to get a list of my installed extensions and update an extension from extensions.gnome.org - using the flatpak. The extensions page initially displayed a message “An unexpected error occurred” but after logging out and in on the desktop it worked. :grin:

#39

I have Flathub repo attached but still no FF app from Flathub shown in Gnome Software.
How can I make it visible? (I know I can install it from CLI)

#40

Does flathub show up as enabled in the Software’s repo list?

1 Like