Firefox snap: remove content interface plug declarations

store-requests
1

We’ve recently been working to upgrade the Firefox snap to core22 together with the gnome-42-2204 content snap. This mostly worked, but the published snap would not auto-connect to gnome-42-2204.

This seems to be due to the snap-declaration delivered by the store, which includes plug rules for the content interface:

$ snap known --remote snap-declaration series=16 snap-id=3wdHCAVyZEmYsCMFDE9qt92UV8rC8Wdk
...
plugs:
  ...
  content:
    allow-auto-connection:
      -
        plug-attributes:
          content: $SLOT(content)
        slot-attributes:
          content: hunspell-dictionaries
        slot-snap-id:
          - bbCAYjcF3ZDMuOhmwCsm6j6KhyDVt2uW
      -
        plug-attributes:
          content: $SLOT(content)
        slot-attributes:
          content: gnome-3-38-2004
        slot-snap-id:
          - rw36mkAjdIKl13dzfwyxP87cejpyIcct
      -
        plug-attributes:
          content: $SLOT(content)
        slot-snap-id:
          - jZLfBRzf1cYlYysIjD2bwSzNtngY0qit
...

As there is a content interface rule defined on the plug side, the slot side rules are ignored for any connection candidate.

The plug rule allows connection to certain slots provided by hunspell-dictionaries-1-7-2004, gnome-3-38-2004, and gtk-common-themes. There’s no rule for gnome-42-2204 though, so that connection fails even though the slot-side declaration would be happy to allow it.

My understanding is that the plug declaration was added because hunspell-dictionaries-1-7-2004 had no slot-side delcaration to allow connection, and it wasn’t clear whether one was desirable. But of course, this meant every other content interface needed to be enumerated in the plug declaration.

While adding gnome-42-2204 to the plug declaration would fix the immediate problem, it just means we’ll be back here again in a few years. I think a better option would be to remove the plug declaration for the content interface entirely.

While a hunspell-dictionaries content interface plug was added to the nightly branch of the snap:

… we never added it to stable branch, instead only relying on the host-hunspell plug to mount host system spelling dictionaries:

So the only part of the plug declaration we’re currently using are the gnome-3-38-2004 and gtk-common-themes cases, which will both auto-connect based on their respective slot declarations.

2

This makes sense - however, the snap declaration is used by all revisions of the snap, so I am not sure we can easily remove these without breaking the use of these older revisions from the nightly/edge channel - unless we are sure none were ever published to the store?

1 Like
3

Just checked the published snap.yaml files with the following command:

curl -H 'Snap-Device-Series: 16' 'https://api.snapcraft.io/v2/snaps/info/firefox?architecture=amd64&fields=snap-yaml' | jq -r '."channel-map"[]."snap-yaml"'

It looks like we’ve still got hunspell-dictionaries plugs on the published 112.0b2-1 and 113.0a1 snaps, which are built from different branches of of the snapcraft.yaml project. Nothing on the stable or candidate channels of either latest or esr has the plug, since I don’t think it ever hit those git branches.

All published snaps have a host-hunspell plug, so those beta and edge snaps would continue to see the same spelling dictionaries as candidate and stable channels do if hunspell-dictionaries no longer auto-connected. And looking at the firefox-snap git history, I think that’s true for any release with these plugs.

Unless there’s other side effects (e.g. would it affect auto-review of the current beta and edge releases?), I still think deleting the plug declaration is the right move. I’ll also look at getting the beta/edge packaging branches reconciled with what we’ve been releasing in candidate and stable.

4

Could we trivially update the snap declaration for the new gnome-42-2204 snap so Firefox can move forward, and then with less pressure, work on the plug declaration removal?

We have some tools that allow us checking how snaps would auto-connect, so I can e.g. given a list of snaps, simulate what the effect of removing the plug would be, for several combinations and/or channels, so we have confidence we won’t break anyone - but I would still prefer to do so without a sword hanging over my head :slight_smile:

  • Daniel
3 Likes
5

I think this is a great idea as an intermediate step before removing the plug declarations entirely. @jamesh if you are ok I can add gnome-42-2204 to the plug declaration of firefox meanwhile @roadmr can run the simulation.

6

@reviewers I went ahead and added this to the latest firefox revision to fix the issue in the meantime. Please let me know if you disagree and we can discuss further steps.

@roadmr can you please run your test now?

7

Adding gnome-42-2204 as an interim measure sounds fine. I would still like to push for removal of the plug declaration though.

As it stands, the plug declaration looks like it will also prevent connection of third party theme snaps to the firefox:gtk-3-themes plug. I don’t think we want to have to update Firefox’s snap declaration each time a new theme snap is approved for auto-connection.

From this experience, I do wonder if it would be worth creating a policy to only create plug declarations or slot declarations for a particular interface but not both. The way connection/auto-connection rules from a slot declaration are ignored if there is a plug declaration for the interface is confusing. And trying to write a plug declaration that matches what an existing slot declaration does risks things getting out of sync should the slot declaration change (e.g. there’s no slots-per-plug: * annotation for Firefox’s theme plugs).

1 Like
8

The hunspell content interface usage in the firefox snap has now been dropped from all channels and it would be safe to drop the plug declaration.

2 Likes
9

@jamesh @kenvandine I have removed the entire content plug declaration for the firefox snap as requested. Please let us know if you experience any issue.

1 Like
10

@emitorino: Just did a full snap remove / snap install, and all the content interfaces auto-connected as expected. So I think the updated snap declaration is working correctly.

1 Like
11

Firefox snap is not installing correctly on Core22 (Rpi4b), as there is no /usr/share/hunspell system directory for the hook to mount from.

Journalctl log: ubuntu systemd[1]: Mounting Mount unit for firefox, revision 3936 via mount-control… ubuntu mount[4105]: mount: /var/snap/firefox/common/host-hunspell: special device /usr/share/hunspell does not exist. ubuntu systemd[1]: var-snap-firefox-common-host\x2dhunspell.mount: Mount process exited, code=exited, status=32/n/a ubuntu systemd[1]: var-snap-firefox-common-host\x2dhunspell.mount: Failed with result ‘exit-code’. ubuntu systemd[1]: Failed to mount Mount unit for firefox, revision 3936 via mount-control.

If I provide a /usr/share/hunspell system directory, say by manually mapping anything to /usr/share/hunspell (like from a hunspell content snap), the install succeeds and firefox works.

How is the firefox snap suppposed to install on a non-classic system? fyi I see gnome-42-2204 (174) on system.

12

It looks like the install is failing due to the snap’s connect-plug-host-hunspell hook failing. It could probably be made to succeed if ignored the error from snapctl mount. I don’t think there is any easy way for the hook to know whether /usr/share/hunspell exists outside the sandbox, so ignoring the error is probably the best it can do.

With that said, I suspect you’ll have trouble getting the snap working on vanilla Ubuntu Core 22. We have got it working with the Ubuntu Core Desktop builds, which include substantially more in the base system (enough to stand up GDM and a graphical login session).

13

I unsquashed on device and added an if -d /usr/share/hunspell test around the mount call in the hook, and ran with try, and resquashed and tested again.

https://github.com/canonical/firefox-snap/pull/52