My application, TurboExecutive turbosmtp-executive-monitor, is an application which allows to show mail statistics in our SMTP Service and it will use a system tray in order to show / hide statistics and close the application.
It’s built with Electron, 'cause I am javascript developers.
Without classic confinement I cannot use the system tray with Electron.
I’m using Tray() just fine in all my electron apps in strict mode …
classic should not be necessary for this … make sure to have the desktop and the unity7 plugs defined for your apps entry in snapcraft.yaml …
I just tried, providing the following in package.json of my project.
Looks like Tray is shown, but contextual menu doesn’t work.
Changing the confinement with classic it works.
"build": {
"productName": "turboSMTP Executive Monitor",
"appId": "io.deliverytech.turbosmtpexecutivemonitor",
"artifactName": "${productName}-${version}.${ext}",
"linux": {
"category": "network",
"target": [
"snap",
"deb"
]
},
"snap": {
"confinement": "strict",
"stagePackages": [
"default"
],
"environment": {
"HOME": "$SNAP_USER_COMMON",
"TMPDIR": "$XDG_RUNTIME_DIR",
"XDG_CURRENT_DESKTOP": "Unity",
"DISABLE_WAYLAND": 1
},
"plugs": [
"avahi-observe",
"browser-support",
"cups-control",
"gsettings",
"opengl",
"home",
"desktop",
"desktop-legacy",
"mount-observe",
"network",
"network-bind",
"network-observe",
"password-manager-service",
"pulseaudio",
"removable-media",
"screen-inhibit-control",
"unity7",
"x11"
]
}
}Well, “my menu does not open” is definitely not enough reason to get classic confinement granted i guess 
check if there are any “DENIED” messages in journalctl while you try to open the context menu to see if you need more inerfaces (i never use electron-builder for any electron apps (but rather electron-packager called from snapcraft.yaml), might be that there is a bug somewhere)
Thanks for support.
And yes, I saw the following:
`mag 12 13:28:06 debba-ThinkPad-T590 dbus-daemon[2920]: apparmor="DENIED" operation="dbus_method_call" bus="session" path="/com/canonical/dbusmenu" interface="org.freedesktop.DBus.Properties" member="GetAll" name=":1.230" mask="receive" pid=58637 label="snap.turbosmtp-executive-monitor.turbosmtp-executive-monitor" peer_pid=3232 peer_label="unconfined"`
So looks like it tried to use the method getAll of org.freedesktop.DBus.Properties interface.
Should I add something in plugs?
you might need the dbus interface …
I tried, but it doesnt’ work.
The only way is to install with --classic flag.
Otherwise until now the tray icon appears, but it doesn’t open the contextual menu.
Do you have some advices?
dbusmenu is supposed to work with the unity7 interface. Is this interface connected (you can see with snap connections turbosmtp-executive-monitor)?
Assuming it is connected, looking at the denial:
We have a rule that is intended to match this:
dbus (receive)
bus=session
path=/{MenuBar{,/[0-9A-F]*},com/canonical/menu/[0-9A-F]*}
interface="{com.canonical.dbusmenu,org.freedesktop.DBus.Properties}"
member=Get*
peer=(label=unconfined),
Note that the ‘path’ in the rule requires the [0-9A-F]* but the ‘path’ in the denial omits this. I know that @popey was looking at a different electron application and had a similar issue and I initially thought that perhaps electron was doing something wrong (and it could be still) but this is a receive rule from the dbusmenu service that is omitting[0-9A-F]* from the path, so perhaps something changed with dbusmenu recently?
@turboSMTP and @popey - are you using a base snap in your resulting meta/snap.yaml? What is the output of snap version on the system where you see the denial?
@kenvandine or @Wimpress - can you have someone confirm that the rules are correct for dbusmenu (I’ll note that this policy is pretty old and it is surprising that we are seeing this change now)?
Classic won’t be granted for this but we’ll figure out why there is a denial with dbusmenu and go from there.
Hello all guys!
In the meantime, thank you all for your interest and for your advice.
Taking a look on GitHub projects using Electron and distributed on Snap, I realized they are using a slightly older version than mine.
So, by chance, downgrading my Electron version from the last stable to 7.3, I was surprised to find that it works correctly with strict confinement, solving my problem.
At this point I would say that the problem lies in the latest versions of Electron, I will try to update in the future by seeing what happens.
For now as far as I’m concerned you can close this thread.
Thanks a lot for your support.
Thanks @turboSMTP. I suggest those that are affected look at the commits after the 7.3.0 tag for changes to shell/browser/ui/views/global_menu_bar_x11.cc as a start.
I’m inclined to include this rule in the unity7 policy:
dbus (receive)
bus=session
path=/com/canonical/menu
interface="org.freedesktop.DBus.Properties"
member=Get*
peer=(label=unconfined),
since it should be ok for the application to receive org.freedesktop.DBus.Properties on the non-app-specific /com/canonical/menu path, but I want to do some investigating. @kenvandine, I’d appreciate someone from the desktop team weighing in.
Hello @jdstrand!
As far as concerned me, it would be great update unity7 policy.
My solution is something like a workaround.
Although it resolved the problem in this topic, oldest versions of Electron don’t have a good support in Snap for other things that previously worked great, for example badge count in app icon.
Currently for me that’s a less worse solution, because in my application it’s more important have the tray fully working.
However, as much as I love the snap ecosystem, I feel obligated at the moment to recommend installation my software with other methods that guarantee the integrity of all the features.
Hope you can solve.
Thanks a lot for your support.
2.45 was just released and I know that the snapd team is preparing 2.45.1 now. Perhaps @mvo or someone from the snapd team can comment on its approximate arrival?
If there are no issues with the validation we will push 2.45.1 to stable on Monday in a week (15.June).