After updating snap version of Firefox (version 87.0-3, Rev 512) the Bookmark Menu becomes unresponsive. Bookmarks can be found by using the Library icon, but this is inconvenient. Is this a problem with the snap package or a new feature of Firefox?
Does not happen in X session.
mozilla.org … they maintain it themselves …
The issue was found while using Ubuntu 20.04.2 in a Wayland session.
The .deb version of Firefox (87.0+build3-0ubuntu0.20.04.2) did not have this issue. Appears to be unique to the snap package.
My bad, I forgot this point…
There is definitely something wrong with this FF: I cannot open a second tab from a link in a mail in TB.
These apparmor denials are indeed the likely cause of the problem. I just tested in a VM, and the problem doesn’t appear to be limited to the bookmarks menu, for me the main window doesn’t even render correctly.
If I manually edit
/var/lib/snapd/apparmor/profiles/snap.firefox.firefox to add a rule to allow reading and writing to
/dev/shm/wayland.mozilla.ipc.* and then reload the profile, then firefox starts and renders correctly.
Just done that:
Excellent, thanks @fthx !
At some point, I wonder if it would be easier to just give snaps a private
/dev/shm in a similar way to how they get a private
/tmp? We keep on running into applications that fall foul of the restrictions.
It seems a bit hit and miss over whether applications or libraries can easily be modified to use the
snap.$SNAP_NAME. prefix for their POSIX shm keys, and we’ve accommodated projects that are too big to adapt to the Snap sandbox in interfaces like
/dev/shm would mean we could stop imposing the naming restrictions on confined applications. The downside would be that segment names would mean different things inside and outside the sandbox. I’m not sure if anything actually depends on this, and the existing rules already make snap-to-snap posix shm communication difficult/impossible.
Same issue running 88 beta 4.
Mmmh, maybe there’s something odd not coming from FF.
Today, trying to upload to GitHub some files, in FF or Chromium:
Well, that’s quite annoying!
I confirm this after reboot:
- go to extensions.gnome.org and click on “add yours”
- try to upload a zip file from /usr/share/gnome-shell/extensions
That’s a separate issue altogether: strict snap confinement doesn’t allow applications to access the host filesystem (with some exceptions that don’t include
Ok but it was clearly not the case maybe one week ago.
I have all my zips in /usr/…/extensions and was uploading them from here, usually, from FF.
So something changed, at least with FF usage.
You might have launched an unconfined version of firefox, once running, future “launches” would just take you to this instance.
So that’s a clear security issue since I never hacked FF snap permissions in any ways, as far as I can remember.
Just TB ones to add printing…
I think firefox was using xdg-desktop-portal for that file picker. That would let the user browse to that location and attach the file. Perhaps portal access isn’t be used anymore.