You’re right Gunnar. Strictly speaking, this is a functional regression, so that’s not looking good.
I filed upstream bug 1732755 to keep track of it. As has already been discussed in the past, there’s no obvious and easy to implement solution, but we’ll work something out. Suggestions welcome.
filed https://bugzilla.mozilla.org/show_bug.cgi?id=1732815 upstream to track the screen sharing issue
This spellchecker thing should be a no-go according to me…
Almost everything I write is through my web browser, and I am changing languages several times a day, I really need this feature. Half the Europeans use several languages in their daily life.
this is one of the reasons why the deb will still be around for the next release, so things can be sorted before the LTS …
While we acknowledged the problem and I agree this is not as convenient as using the host’s hunspell dictionaries, please note that you can install spellchecking dictionaries in firefox from about:addons, which works around the problem.
Clicking links in Evince to open them in Firefox does not work:
$ evince
env: ‘/snap/bin/firefox’: Permission denied
see also the Apparmor denial
= AppArmor =
Time: Oct 1 11:37:16
Log: apparmor="DENIED" operation="exec" profile="/usr/bin/evince" name="/usr/bin/snap" pid=20253 comm="env" requested_mask="x" denied_mask="x" fsuid=1001 ouid=0
File: /usr/bin/snap (exec)
Suggestions:
* adjust snap to ship 'snap'
* adjust program to use relative paths if the snap already ships 'snap'
So it’s rather a problem with the apparmor browser abstraction file (/etc/apparmor.d/abstractions/ubuntu-browsers), but something that needs to be resolved nonetheless.
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 …
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.
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
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.conf file 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:
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
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.