Feature Freeze Exception: Seeding the official Firefox snap in Ubuntu Desktop

seb128 · October 6, 2021, 11:15am

Updates aren’t going to bring in the snap since so you should manually reinstall yes

oSoMoN · October 6, 2021, 11:24am

That’s because the firefox snap is published by Mozilla, with no visible Ubuntu branding. Snaps work on a lot of linux distributions, not just Ubuntu.

corradoventu · October 6, 2021, 12:25pm

Thanks, I will use the .deb version while available or until the WebGL problem is fixed.

oSoMoN · October 6, 2021, 1:39pm

That’s a good point, and I think it wouldn’t be too difficult to reset custom content handlers when doing the initial profile import, but I’m failing to observe the problem here. Here’s how I tested (in a clean 21.04 VM):

installed xpdf
ran the firefox deb, opened about:preferences and associate PDF files to /usr/bin/xpdf, verified that PDF files are indeed being opened with xpdf
closed the deb, installed the snap from the candidate channel, ran the snap, observed that the profile got imported
opened about:preferences, observed that the PDF content type was now associated to “Use the default system application”, instead of “use xpdf”
tried opening a PDF file, got a dialog asking me what to do, with the pre-selected option being “Open in firefox”

Could it be that it happens to just work for PDF, but doesn’t for other content types? Would you mind filing a bug report with details on how to reproduce the problem?

ppd · October 6, 2021, 2:17pm

I tried the migration on my notebook and I can’t reproduce the problem there either. The action gets reset and everything is fine. I wonder where that glitch came from for me. But the migration clearly does the right thing.

marianrh · October 6, 2021, 5:09pm

Thanks @oSoMoN! Setting the policy works, it is picked up by the Firefox snap. However, the feature I’m trying to enable (Kerberos/SPNEGO authentication) unfortunately does not work. I’m setting this policy (as documented at https://github.com/mozilla/policy-templates/blob/master/README.md#authentication):

{
  "policies": {
    "Authentication": {
      "SPNEGO": ["<my_authentication_server_hostname>"]
    }
  }
}

This is shown by Firefox in about:policies, and Firefox also correctly shows the resulting config entry network.negotiate-auth.trusted-uris=<my_authentication_server_hostname> in about:config. However, Kerberos authentication does not work, without any error messages. (It did work in the deb-based Firefox with the exact same config entry.)
Please tell me how I can help that this gets fixed. The first step would probably be to create an issue, but which is the correct issue tracker for the Firefox snap?

oSoMoN · October 6, 2021, 5:26pm

This is probably similar to bug #1849346 in the chromium snap. Please file a bug with as many details as possible, specifying that this is a snap-specific issue, and ideally provide minimal steps to set up an environment for reproducing the issue (I’m not familiar with Kerberos authentication). Thanks!

marianrh · October 8, 2021, 7:23am

Hi @oSoMoN, I created a bug at https://bugzilla.mozilla.org/show_bug.cgi?id=1734791. I added a list of files, directories, and environment variables that I believe the snap needs to have access to in order for authentication to work. I’d be happy to test an updated snap for you.

After we get Firefox working, maybe the same steps can be applied to fix the Chromium snap as well.

mohan-ram · October 9, 2021, 12:10pm

Not a Choromium user here, but I also think Thunderbird snap needs to be brought up to top tier as well and become the default for the next LTS. Has been rock solid to use in my experience.

nicocarbone · October 14, 2021, 5:36pm

I am sorry if I am adding noise, but now that 21.10 is stable I just wanted to say this again: snapped
firefox cold start time is still too slow and a clear regression from the .deb version. I am using a fairly powerful PC (Rizen 2600, 32gb RAM, NVME SSD) and a cold start of firefox can take more than 10 seconds.

I don’t have anything against snap in general, in fact I prefer snapped apps when available. But right now this is not a good user experience. And people see it. See, for example, this review done by The Linux Experiment youtube channel: https://www.youtube.com/watch?v=SXfpbsCXUmE

xlmnxp · October 14, 2021, 7:39pm

the Arabic issue is there in stable release
and https://github.com/snapcore/snapcraft/pull/3586 didn’t merge

I think when it merge the firefox issue will fix, and still there other issue @gunnarhj mention above

(libreoffice and gedit use system font for Arabic, but firefox not)

firefox, snap-store, telegram and chromium (maybe a lot of other applications too) don’t use system font for render Arabic

but only slack use system font for Arabic to render

ogra · October 14, 2021, 11:00pm

do not worry, snaps are rolling packages, they are not bound to the underlying OS release and fixes get merged constantly, it will surely land soon and be picked up by all snap rebuilds then …

ogra · October 14, 2021, 11:04pm

it does not take more than 3-5 on any system here, might make sense to open a topic on https://forum.snapcraft.io and attach collected info from a run with --trace-exec like in:

nicocarbone · October 15, 2021, 1:02pm

Here is the output from my --trace-exec. I will open a topic on snapcraft forums.

snap run --trace-exec firefox
[sudo] contraseña para nicolas: 
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
amdgpu: os_same_file_description couldn't determine if two DRM fds reference the same file description.
If they do, bad things may happen!
Slowest 10 exec calls during snap run:
  0.475s snap-update-ns
  0.509s /usr/lib/snapd/snap-confine
  0.070s /snap/firefox/631/snap/command-chain/snapcraft-runner
  0.344s /snap/firefox/631/snap/command-chain/desktop-launch
  0.070s /usr/bin/dbus-send
  0.093s /usr/bin/xdg-settings
  0.061s /usr/bin/xdg-settings
  14.192s /snap/firefox/631/usr/lib/firefox/firefox
  10.890s /snap/firefox/631/usr/lib/firefox/firefox
  10.077s /snap/firefox/631/usr/lib/firefox/firefox
Total time: 28.494s

geminis3 · October 15, 2021, 2:05pm

Gave Ubuntu 21.10 a try on a live USB, VAAPI is broken on Firefox Snap, it keeps looking for a VA driver inside its own Snap folder instead of using the system wide one.

Vainfo

ogra · October 15, 2021, 2:10pm

i believe
https://gitlab.gnome.org/Community/Ubuntu/gnome-sdk/-/merge_requests/31
together with
https://github.com/snapcore/snapcraft/pull/3591
are supposed to fix this…

dimelotu · October 16, 2021, 7:46pm

Hi, I’ve been trying a persistent live usb (created with rufus) in 2 laptops. At first booting apps like firefox are working. But the following bootings the apps don’t launch, included the application manager. launching the apps frm the console produces this error:

snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks: Operation not permitted

Any solution? thanks

ogra · October 17, 2021, 12:07am

better open a thread on https://forum.snapcraft.io in the snapd category, that way the developers will see it …

lucap · October 20, 2021, 7:16am

/Downloads/firefox.tmp

I think that it would be better if the temp folder was hidden or moved to the snap folder as family members have thought that firefox downloaded and installed software without their input , i’ve also had to explain to my elderly Uncle more than once that he can ignore it.

gunnarhj · October 21, 2021, 12:45pm

gunnarhj:

The issue can be worked around temporarily by opening the file:

~/snap/firefox/current/.config/fontconfig/fonts.conf

for editing and adding this line:
<include ignore_missing="yes">/etc/fonts/conf.d</include>
And a more proper fix is on its way:

https://github.com/snapcore/snapcraft/pull/3586

Speaking of font configuration for the Firefox snap, another aspect of it was brought up in this Ask Ubuntu question:

fontconfig that survives Firefox snap updates?

It’s about the ~/snap/firefox/current symlink switching target when the snap is updated. I saw this comment in a thread about the Chromium snap.

@oSoMoN: Was that comment ever followed up with a bug, or is the issue otherwise being dealt with?