Firefox update 87.0-3 breaks Bookmark Menu

snap
11

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
12

Same issue running 88 beta 4.

13

Mmmh, maybe there’s something odd not coming from FF.

Today, trying to upload to GitHub some files, in FF or Chromium:

image

Well, that’s quite annoying!

14

I confirm this after reboot:

  1. go to extensions.gnome.org and click on “add yours”
  2. try to upload a zip file from /usr/share/gnome-shell/extensions
  3. fail
15

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/).

16

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.

17

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
18

You might have launched an unconfined version of firefox, once running, future “launches” would just take you to this instance.

19

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…

image

20

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.

21

I take advantage of the presence of all Canonical people here :wink: to ask when browsers snaps (Chromium, FF) will allow to use GNOME Integration add-on which make it possible to install extensions?

I know it’s somewhat off-topic but that point makes an user unable to install any extension in a cool way… (Is there an easy way I don’t know except website? There was Tweak Tool & Ubuntu Software. RIP.) This question has been asked some time ago, but without success.

22

About the /usr/share picking issue.
Under X11, I can access it:
image

So, if access to /usr/share is not intended, that’s a confinment issue.

- firefox
notes:               
  private:           false
  confinement:       strict
  devmode:           false
  jailmode:          false
  trymode:           false
  enabled:           true
  broken:            false
  ignore-validation: false
base:         core18
snap-id:      3wdHCAVyZEmYsCMFDE9qt92UV8rC8Wdk
tracking:     latest/beta
refresh-date: aujourd'hui à 08h21, heure des Rocheuses
channels:
  latest/stable:    87.0-3      2021-03-25 (512) 153MB -
  latest/candidate: 87.0-3      2021-03-22 (512) 153MB -
  latest/beta:      88.0b5-1    2021-03-30 (518) 154MB -
  latest/edge:      ↑                                  
  esr/stable:       78.9.0esr-1 2021-03-22 (513) 148MB -
  esr/candidate:    ↑                                  
  esr/beta:         ↑                                  
  esr/edge:         ↑                                  
installed:          88.0b5-1               (518) 154MB -
23

confined access to /usr/share is fine as long as the snap uses the desktop portal as a file picker (the portals do copy files around transparently into a place where the snapped app can accesss them while the UI shows you the actual path) …

as ken said above already, it looks like firefox used the portal when it worked, there are no security issues here, rather bugs with the xdg-desktop-portal installation on your system or with the way firefox uses them.

24

Ok, I just have found why FF 87 snap has issues and not FF 86…

I know that some of you already know this BR but, for the sake of Firefox, it allows to simply enter:
DISABLE_WAYLAND=1 firefox
in a terminal while waiting for a proper fix.

25

Thanks @fthx
I can confirm that this resolves the issue of the bookmark menu not working. However, since I also have the firefox deb version installed, I found that I had to close out of the .deb version completely and enter the following into terminal:

DISABLE_WAYLAND=1 /snap/bin/firefox

this also leaves the terminal command open until you close firefox. Interesting that if the .deb version of firefox is open, the above command will open another .deb firefox.

26

… and my workaround does not solve the issue that avoids Thunderbird to open a tab when FF is already opened.

It’s quite annoying that this happens when Hirsute will default Wayland. I don’t know if this issue exists in Hirsute, though.

27

this has nothing to do with the packaging system, it is an internal “feature” of firefox since years … before this became a default you had to call “firefox --remote” to get this behaviour and a simple “firefox” always opened a new window.

1 Like
28

[Related to this thread]

I was reading this:

Does the Thnderbird 78.9 snap use Wayland too?

29

I can answer to myself: no. (I was testing some windows stuff for BaBar extension!)

30

I use this old thread, I think it could alert some useful people. I do use Focal, Wayland session, and the upcoming Firefox 89.

Here are the points that make FF snap quality still problematic, at the moment:

  • cannot open /usr folder, e.g.
  • cannot move bookmarks (maybe caused by the new UI)
  • media window is not created with respect to previous settings (bottom right, size) and is not above all windows (have to set it manually)
  • cannot open links in FF from Thunderbird when FF is already open

Only point #2 is new. So, I understand every dev concerns but from an user POV, it’s quite annoying. So, I maintain, since FF is a main software for Ubuntu, that maybe Mozilla should revert to previous FF86’s X11 back end before some issues have been cleared.

Just my point of view. :slight_smile: