#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
#41

Yes it does. Sorry, on a second look the app actually shows up, it just without icon and many (null) lines present in the GNOME Software, but on Flathub site it’s OK.

1 Like
#42

Yay!

A word of warning though: Updating an extension from extensions.gnome.org will update the files on disk, but not the loaded extension. You have to restart your session for the update to really take effect.

1 Like
#43

Anyone else experiencing this?

When I open a file and choose to save to disk it always defaults to the /run/usr/{UID}/doc/{ID} path inside the Flatpak container. I’ve seen more Flatpaks do this, which is quite unintuitive.

Why doesn’t it remember the last used path? I’ve checked about:config and browser.download.lastDir is also set to this /run/usr/{UID}/doc/{ID} path in stead of the actual path last used for saving a file. Any solution?

#44

Yes.
Also for me it completely freezes the computer (restart needed) when zooming in or out in Google Maps.

#45

How to check if Wayland/VAAPI acceleration is actually used?