more likely a missing entry in /etc/apparmor.d/abstractions/evince to allow execution access to /usr/bin/snap … but that will need input and review by the security team i guess …
4 Likes
Hi @ogra and others, I’m globally setting some Firefox preferences by placing files in /usr/lib/firefox/browser/defaults/preferences. The Snap version does not seem to read this directory. How can I set global preferences for the Snap version?
globally writable dirs for snap packages usually live in /var/snap/<snapname>/current or .../common, not sure if firefox currently uses that dir but this is definitely where system wide configs would live in the snap…
I would like to add that not just Google Earth but I noticed that live radar on Accuweather.com and on Weatherbug.com do not work as well. All three Google Earth, weather websites all work just fine in Chromium (which is also snap application).
A little bit off-topic but has to be said: the default “Ubuntu and Free Software links” are missing on the new, snap version of Firefox. I also suggest adding a link to either the Ubuntu homepage or AskUbuntu as a shortcut on the Firefox Home tab.
1 Like
One thing I’m observing when starting from a migrated profile (deb -> snap) is the following:
Certain content types might have a default handling program associated that worked in the past, e.g. snap:// would have been associated the snap store/ubuntu software/gnome software application. Now, in the snap confined world, such direct calls will not work and just silently fail (you get something like “env: ‘snap://app’: No such file or directory” on the console).
In the snap, you should likely always use xdg-open or the portal in general. However, the average user might not discover that they can reset the association in the settings and will be frustrated by the lack of feedback.
I think those content to app associations must be reset on migration (or amended).
@ppd @ogra Could evince just use xdg-open instead of calling firefox directly? Allowing evince to call /usr/bin/snap directly is not great for security, since i.e. a malicious PDF could embed something like snap install evil --devmode and escape the AppArmor sandbox that is setup for evince AIUI
1 Like
that would be a question to the desktop team i guess … i have not looked at the evince deb in a long time (nor at upstream code) note that this apparmor rule is actually from the deb package …
Another area with a need to look closer into is fonts.
When playing around with the Firefox snap, I see that it uses NotoSansCJK-Regular.ttc for CJK scripts. I don’t find that file in the snaps, which indicates that /etc/apparmor.d/abstractions/fonts is in use.
Nevertheless, the symlinks in /etc/fonts/conf.d seem not to work as expected. It might be due to an ordering issue. I mean, the order in which the font configuration files are read by fontconfig is crucial — hence the prefix numbers in the file names. Can it possibly be that it’s configured to read /snap/gnome-3-*-*/current/etc/fonts/conf.d first, and /etc/fonts/conf.d only afterwards? In that case that may be one explanation why the system’s font config files are ignored to a large extent.
Edit:
In /snap/gnome-3-38-2004/76/etc/fonts/fonts.conf I see this section:
<!--
Load local system customization file
-->
<include ignore_missing="yes">conf.d</include>
Should an entry representing the system’s /etc/fonts/conf.d be added to or replace that entry?
Edit 2:
In an IRC discussion I was asked to provide a specific, reproducible example. Here it is:
-
Generate a Chinese locale:
sudo locale-gen zh_CN.UTF-8 -
Start firefox with that locale applied:
LC_CTYPE=zh_CN.UTF-8 firefox -
Go to https://zh.wikipedia.org
-
Use More tools -> Web Developer Tools to examine which fonts are used.
-
If firefox is a .deb, then you see “Fonts Used: Noto Sans CJK SC” as expected.
-
If firefox is a snap, then you see “Fonts Used: Noto Sans CJK JP” which means that some characters are rendered using the equivalent Japanese glyphs, which is not optimal and a regression for users with a Chinese locale.
-
-
In other words: The
/etc/fonts/conf.d/69-language-selector-zh-cn.conffile was not loaded by the snap.
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:
4 Likes
Thanks for the reply @ogra! How can I find out whether the Snap really does read config from the directories you mentioned and also what directory structure the Snap expects?
It calls g_app_info_launch_default_for_uri (https://gitlab.gnome.org/GNOME/evince/-/blob/master/shell/ev-window.c#L6640). A similar problem from the perspective of a snapped application: Opening a local file with its default application - snapd - snapcraft.io
1 Like
The recommended way of setting preferences for the snap is through policies (in /etc/firefox/policies/policies.json).
I am happy to share that the problem with WebGL in Wayland sessions has been identified, and a fix for it is being reviewed, so hopefully the regression will be gone in Firefox 94.
3 Likes
Updates aren’t going to bring in the snap since so you should manually reinstall yes
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.
Thanks, I will use the .deb version while available or until the WebGL problem is fixed.
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:preferencesand 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?
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. 
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?