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?
+1, very annoying. Wayland session (I’ll test X session).
Logs:
Does not happen in X session.
Just Wayland.
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.
@mmaurer @fthx would one of you mind filing an upstream bug and linking it to this post? Don’t forget to mention that this is the snap package and that it affects only wayland sessions. Thanks!
1 Like
Just done that:
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 browser-support.
A private /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.
2 Likes
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
- fail
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 /usr/share/).
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.
This was discussed and the option of allowing for an opt-in flag to this behavior in snap.yaml was thrown on the table, @pedronis or @jdstrand might recall some of the details.
1 Like
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.