1732755 - Firefox snap cannot access host's hunspell dictionaries for spellchecking

Status: RESOLVED FIXED

(Release Engineering Graveyard :: Release Automation: Snap, defect)

Description

[Olivier Tilloy]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:92.0) Gecko/20100101 Firefox/92.0

Steps to reproduce:

Initially reported here: https://discourse.ubuntu.com/t/feature-freeze-exception-seeding-the-official-firefox-snap-in-ubuntu-desktop/24210/93.

Strictly-confined snaps cannot see spellchecking dictionaries installed on the host system at /usr/share/hunspell (typical install location on Debian-based systems). As a result, users have to explicitly download spellchecking dictionaries from about:addons.

This is not strictly a blocker, but one of those (important) details that make the snap package feel less tightly integrated with the host system.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Toolkit::Add-ons Manager' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Gunnar Hjalmarsson]

The bot thinks this is a "Toolkit::Add-ons Manager" issue. Well, I'm not sure of that.

On Ubuntu 21.04, where my Firefox is still installed via a .deb file, I can select any dictionary in /usr/share/hunspell for spellchecking. But if I go to about:addons none of them are listed there. My impression is that "Toolkit::Add-ons Manager" only cares about dictionaries compiled into .xpi files, and that the access to the host's dictionaries in other file formats is handled through some other mechanism.

Another observation, which may or may not be useful (probably not): The IBus plugin ibus-typing-booster makes use of hunspell dictionaries. If I install and enable ibus-typing-booster I can choose among the /usr/share/hunspell dictionaries, and I can successfully use the plugin also with the Firefox snap. So IBus serves as a backdoor to those directories which the snap does not see. However, I can still not enable any such dictionary for pure spellchecking.

Comment 3

[Marco Trevisan (Treviño)]

There's an huspell content snap, maybe that can be used to source the dictionaries?

Comment 4

[Gunnar Hjalmarsson]

That's interesting. But how exactly would it work?

What first comes to mind is that if you would make use of that hunspell snap, you would make all hunspell dictionaries available in the Firefox snap. And if that's the case, I'm not sure it would be an improvement.

People who type in more than one language may want to switch the spellchecking language several times a day. And when doing so, it's not very convenient to have to browse a long list with languages you never use. Ideally you want to see a list with only the languages you are interested in.

So under that assumption, I can think that many multilingual users would prefer to manually add the dictionaries they are interested in to their profile over having all the dictionaries installed.

My understanding is that it's this list we are talking about:

https://addons.mozilla.org/en-US/firefox/language-tools/

There are quite a few of them... (As regards the language packs, I see that they are all shipped with the snap. But that's not a problem since the 'normal' user does not switch display language frequently, and the default language pack is determined by the current locale.)

Comment 5

[Gunnar Hjalmarsson]

I installed the hunspell-dictionaries-1-7-2004 snap and noticed that the hunspell dictionaries are located in

/snap/hunspell-dictionaries-1-7-2004/current/usr/share/hunspell

They are plain text files (and symlinks), and I suspect they originate from all the hunspell-* APT packages built by libreoffice-dictionaries. This observation does not make me less hesitating, though.

As a test I copied the Swedish dictionary to:

~/snap/firefox/current/usr/share/hunspell

but the Firefox snap does not see it.

At first hand I think the confinement should be relaxed so the snap sees /usr/share/*spell system directories just like the non-snap Firefox program does.

OTOH, if there was a dedicated spot in the ~/snap/firefox directory where the snap sees hunspell *.dic and *.aff files, an option might be to let a user owned script copy dictionaries as needed. Not sure about the details for this latter idea — at best it has the potential to address this bug for Firefox users.

Comment 6

[Olivier Tilloy]

Sébastien took some time to experiment with plugging the hunspell snap in firefox, and while it works as advertised, the downside as highlighted by Gunnar is that it makes every single language available in the spellchecking contextual menu, therefore making it cumbersome to switch between a limited set of languages on a frequent basis.

Assuming relaxing the confinement to expose /usr/share/*spell from the host to the snap is a viable option from a security perspective, I have a dumb question: is the file format of the dictionaries in those folders forward- and backward- compatible? I.e., are files generated for/by the version of hunspell in e.g. Ubuntu 21.10 going to be readable by the version of hunspell in Ubuntu 20.04 (which is currently used as a base to build the firefox snap)? And vice-versa, when using the snap on an older release, e.g. Ubuntu 18.04.

Comment 7

[seb128]

Gunnar, how would you determine which dictionaries are needed? We could copy or activate the ones corresponding to locales which are installed on the system but would that be correct? Also if we copy from the system, then we need to answer's Olivier question about compatibility between versions. Otherwise there is always the option to use the content sharing and copy a selected of dictionaries from there to another location and let DICPATH points to the new directory.

Comment 8

[Gunnar Hjalmarsson]

@Olivier: As regards forwards/backwards compatibility I'm not 100% sure. Can't recall any situation when that has been an issue, though. I'll do a couple of simple tests and see if I can identify an incompatibility case.

@Sebastien: Stricly speaking the locale has nothing to do with typing. Nevertheless, via check-language-support and pkg_depends we use the locale to guess which language support a user may be interested in. So if you install Ubuntu in French, you get French spellchecking, and if you later add some other language via language-selector-gnome you get what's considered suitable language support for that language...

But the user also can install additional spellchecking support, and uninstall such support which they don't want to see. My concern here is that doing these things via snap(s) would make it impossible for the users to tweak the available support to their liking.

Comment 9

[Mattia Rizzolo]

@Olivier the format for the hunspell dictionaries comes from very literally more than a decade ago, and AFAIK hasn't changed since. At the very least, we are shipping dictionaries that haven't been touched since a decade and they keep working.
I'm also not aware of anything that would make them not backward-compatible.

FWIW, I also approve more of the idea of having the snap break out and look into /usr/share/hunspell rather than embedding them.

Comment 10

[Gunnar Hjalmarsson]

I took another look at this, and learned that there are two ways to tell Firefox where to look for spellchecking dictionaries:

1. Set spellchecker.dictionary_path in about:config

2. Set the environment variable DICPATH

As an experiement I

• created the /home/gunnar/snap/firefox/current/.local/share/hunspell directory

• copied the Swedish hunspell dict into the directory

• set (and exported) DICPATH=/home/gunnar/snap/firefox/current/.local/share/hunspell

It works. The Firefox snap now lets me select between English (US) and Swedish spellchecking.

So to fix this regression in Ubuntu, we would need to

• Fix the AppArmor profile so Firefox can read /usr/share/hunspell

• Set DICPATH=/usr/share/hunspell (maybe in /etc/environment)

Comment 11

[Gunnar Hjalmarsson]

Since the snap will be used on multiple distros, and it's not safe that /usr/share/hunspell is used everywhere, I had a look at the source code of the ibus-typing-booster package which makes heavy use of hunspell dictionaries. That list of locations may speak for an AppArmor rule along these lines:

/usr/{,local/}share/{hunspell,myspell}/** r,

Comment 12

[Gunnar Hjalmarsson]

snapd pull request submitted: https://github.com/snapcore/snapd/pull/11025

Comment 13

[Gunnar Hjalmarsson]

pam merge request submitted:

https://code.launchpad.net/~gunnarhj/ubuntu/+source/pam/+git/pam/+merge/411567

Comment 14

[:gerard-majax]

Gunnar, your snapd PR is not yet merged, are you sill working on that?

Comment 15

[Gunnar Hjalmarsson]

@Alexandre: Thanks for asking.

No, I'm not working on the snapd PR ATM. I think I have provided the input on the matter I'm able to, but the discussion stalled, and I think others with more technical (especially snap related) skill need to help land a working solution.

Comment 16

[:gerard-majax]

https://forum.snapcraft.io/t/the-hunspell-dictionaries-content-snaps/7160 + https://launchpad.net/hunspell-dictionaries-snaps + https://git.launchpad.net/hunspell-dictionaries-snaps are hunspell dictionnaries really two years old for Snap?

Comment 17

[:gerard-majax]

diff --git a/snapcraft.yaml b/snapcraft.yaml
index 85d9903..a2928b3 100644
--- a/snapcraft.yaml
+++ b/snapcraft.yaml
@@ -13,6 +13,7 @@ apps:
     desktop: firefox.desktop
     extensions: [gnome-3-38]
     environment:
+      DICPATH: "$SNAP/usr/share/hunspell"
       GTK_USE_PORTAL: 1
       HOME: "$SNAP_USER_COMMON"
       PIPEWIRE_CONFIG_NAME: "$SNAP/usr/share/pipewire/pipewire.conf"
@@ -52,6 +53,10 @@ plugs:
   etc-firefox-policies:
     interface: system-files
     read: [/etc/firefox/policies]
+  hunspell-dictionaries:
+    interface: content
+    default-provider: hunspell-dictionaries-1-7-2004
+    target: $SNAP/usr/share/hunspell

 layout:
   /usr/share/libdrm:

This allows to get all dictionnaries we have from the hunspell snap.

Comment 18

[:gerard-majax]

Francesco, I'd like your opinion on how handling those dictionnaries.

The hunspell snap provide a lot of them, and it was suggested on the snapd PR to limit the view of those dictionnaries only to those installed on the system, to avoid flooding the user with a lot of (potentially useless for them) dictionnaries.

Do you think we should indeed implement that filtering ?

Comment 19

[Francesco Lodolo [:flod]]

Listing all the dictionaries available is definitely not a great user experience [1], so we should filter them.

Only showing the dictionaries installed in the system sounds like a good idea to me, because it would also mimic the behavior of a non-snap Linux build.

[1] We already see the occasional complaint from Linux users because their distro installed too many dictionaries, especially for English variants.

Comment 20

[:gerard-majax]

Attachment: GitHub Pull Request

Comment 21

[:gerard-majax]

This is merged, and will hit Firefox Snap's edge channel in the next hours