Opera requests auto-connect to gnome-3-28-1804 interface

Hello, @jdstrand @kenvandine. Any update about the default-provider issue?

I built a new package with the snapcraft candidate (3.9.3) and the default-provider issue is fixed. You can find this new snap on opera-developer’s edge channel (67.0.3540.0).

However, I still need to connect gnome-3-28-1804 manually to make opera work:

snap connect opera-developer:gnome-3-28-1804 gnome-3-28-1804

Could you have a look at the auto-connect problem again? Thanks a lot!

@kenvandine (or someone from the desktop team) or perhaps @zyga-snapd, can you comment?

I don’t know what is happening here, but I can confirm what @xshi is seeing. I installed opera-developer from the edge channel in a clean VM, and gnome-3-28-1804 didn’t get auto-connected. This can be reliably reproduced.

Happy new year everyone!

I just reinstalled and tested the opera-developer snap on edge channel again. I can still reproduce the issue.

Is there any news about this? The issue has been preventing us from updating Opera on snap store for more than I month now.

@zyga-snapd - can you comment?

Its been close to 2 months now since Opera snap version was updated. Two newer browser version releases (non-snap formats) have happened during this period.

Please understand that for people on fresh install of Ubuntu flavors 19.10, Opera Snap is an easier way to get required chromium codecs (which are being shipped as snap by default from Ubuntu) for videos to play on browser.

In spite of an Opera developer requesting repeatedly for support in resolving issue (s) which is preventing them from releasing newer version, it is disappointing to see no help from concerned folks at Snap team. Doesn’t make for a great impression guys.

Snap team, please provide the required help to Opera developers soon so that we consumers can benefit from newer releases.

1 Like

Canonical Team, please fix the issue.

I’m looking at this issue now. Using snapd 2.42.2 on Fedora 31, having installed opera-developer I can see the following thing:

The snap defines several content plugs, among them gnome-3-28-1804 with a default provider of the same name. What was weird is that despite having it installed it was not auto-connected upon installation. This is unexpected. In fact out of all the content interfaces only chromium-ffmpeg was connected. I wonder if this is in any way related to the arity work that was done in snapd recently.

I’m looking into the code to see why.

Having used snap known snap-declaration I scanned the output for the declaration of opera-developer and found this:

type: snap-declaration
format: 2
authority-id: canonical
revision: 3
series: 16
snap-id: Qu7SvRkGy1tMWSmmxEcK7jTgssFDHHp6
plugs:
  browser-support:
    allow-auto-connection: true
    allow-connection: true
  content:
    allow-auto-connection:
      -
        plug-attributes:
          content: $SLOT(content)
        slot-snap-id:
          - XXzVIXswXKHqlUATPqGCj2w2l7BxosS8
publisher-id: JILUl2YHFAreIPbjDCgh7HDCwDlhnBpd
slots:
  dbus:
    allow-connection:
      -
        slot-attributes:
          name: com.opera.opera-developer
    deny-auto-connection: true
snap-name: opera-developer
timestamp: 2019-11-22T20:45:53.487824Z
sign-key-sha3-384: BWDEoaqyr25nF5SNCvEv2v7QnM9QsfCc0PBMYD_i2NGSQ32EF2d4D0hqUel3m8ul

For context, snap declaration is a snapd assertion given to snapd by the store. It contains special language that grants non-default behaviour to a specific snap. It is further documented on

On first read of the resulting assertion I suspect that in absence of other declarations, only single auto-connection for the content snap is allowed.

@jdstrand I think the solution is to issue a new snap declaration for the affected set of opera snaps to allow them to auto-connect to the current set of content interfaces that they desire.

@kenvandine what should be the access rules for chromium-ffmpeg? All this would be greatly simplified if it sported its access rules (like the gnome-* snaps) instead of having each snap using it doing it.

More generally the brittleness here is related to the rules for snap-declarations that have fairly a blunt approach to simplify reasoning ( plug snap rules mask slot snap rules which mask plug base decl rules which mask slot base decl rules ) against the fact that in practice content is one interface implementing a family of them (one per content label value).

@pedronis: I’m not sure I understand what you mean by “access rules”. The usage documentation for chromium-ffmpeg shows how a consumer snap needs to declare a corresponding plug in its snapcraft.yaml, and as far as I can tell it doesn’t differ from how consumer snaps connect to e.g. the gnome-3-28-1804 content snap.

The documentation mention asking for auto-connection on a case-by-case basis. Do we have a reason to limit that vs allowing any snap with the right plug definition to auto-connect to these libraries?

I don’t see a reason not to allow any snap to consume chromium-ffmpeg without having to go through the auto-connection request. This would certainly make it easier for third-party browser snaps (such as opera).

Unless there’s a licensing or security concern, maybe?

Hello @zyga-snapd. Thank you very much for checking this issue. Is there any news on your side?

Please feel free to contact me if you have anything you need to change in the Opera snap.

This is something that the store team needs to handle.

I’ve done this just now for opera-developer, opera-beta and opera. I tested that auto-connect is happening correctly with:

$ snap interfaces opera-developer
Slot                                   Plug
chromium-ffmpeg:chromium-ffmpeg-93464  opera-developer
...
gnome-3-28-1804:gnome-3-28-1804        opera-developer
gtk-common-themes:gtk-3-themes         opera-developer
gtk-common-themes:icon-themes          opera-developer
gtk-common-themes:sound-themes         opera-developer
...

$ snap interfaces opera-beta
Slot                                   Plug
chromium-ffmpeg:chromium-ffmpeg-93464  opera-beta
...
gnome-3-28-1804:gnome-3-28-1804        opera-beta
gtk-common-themes:gtk-3-themes         opera-beta
gtk-common-themes:icon-themes          opera-beta
gtk-common-themes:sound-themes         opera-beta
...

$ snap interfaces opera
Slot                                   Plug
chromium-ffmpeg:chromium-ffmpeg-93464  opera
...
gnome-3-28-1804:gnome-3-28-1804        opera
gtk-common-themes:gtk-3-themes         opera
gtk-common-themes:icon-themes          opera
gtk-common-themes:sound-themes         opera
...

I noticed that opera didn’t pass automated review due to it adding the dbus interface, and granted a snap declaration for that as well.

1 Like

Thank you very much for all your help. It’s indeed working now. I just released new versions of Opera and Opera Beta.

@Burner2k @spyke Please free feel to contact me if you still have problem on launching Opera after you update to the new version.

1 Like

Just installed opera 66.0.3515.44 rev.63 from stable – works fine.

1 Like