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

#46

I see similar for print-to-file from a browser page. Default file destination is inside the container: /home/USER/.var/app/org.mozilla.firefox/cache/tmp. I have to overide this every time.

#47

and this should not hurt I guess

sudo flatpak override --nosocket=x11 org.mozilla.firefox
`flatpak run org.mozilla.firefox` runs system’s firefox instead of flatpack’s
#48

about:support will tell you the truth.

I use all these tweaks:
layers.acceleration.force-enabled
gfx.canvas.azure.accelerated (you have to add this one yourself to equal true)
gfx.webrender.all
gfx.webrender.compositor
gfx.webrender.compositor.force-enabled
gfx.webrender.enabled
gfx.webrender.precache-shaders
gfx.webrender.quality.force-subpixel-aa-where-possible
media.hardware-video-decoding.force-enabled
media.ffmpeg.vaapi.enabled
media.ffmpeg.low-latency.enabled
webgl.force-enabled
webgl.all-angle-options
webgl.msaa-force
dom.webgpu.enabled (doesn’t work yet)

They all appear to be enabled according to about:support and nothing breaks for me.