Firefox flatpak on flathub beta

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.



A word of warning though: Updating an extension from 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

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

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

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

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.

and this should not hurt I guess

sudo flatpak override --nosocket=x11 org.mozilla.firefox

about:support will tell you the truth.

I use all these tweaks:
layers.acceleration.force-enabled (you have to add this one yourself to equal true)
dom.webgpu.enabled (doesn’t work yet)

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

Just a postscript about printing (sorry pun intentional) - printing to CUPS has been broken on the Flatpak build of Firefox for almost a year now. This may soon be fixed with a testing build available in the flathub-beta repository to try it out later this week.

Mozilla bug tracking this issue: 1712555 - Printing doesn't work in the Flatpak version of Firefox
cheers, joe.

1 Like

That’s great to hear, this has been an inconvenience for quite a while!

1 Like