Greatly simplified electron kiosk snaps

doc
1

Over the recent weeks it came up a lot in support that our electron kiosk tutorials are complicated, outdated and partially do not function anymore on modern Ubuntu Core installs …

I took a stab at trying to simplify the whole setup a little with modern snapcraft features like using extensions and build snaps to create an electron kiosk snap to run on top of mir-kiosk…

The outcome of this work can be found for cloning and modifying for your personal electron project under:

and here is the example snapcraft.yaml from this tree using the gnome-3-28 extension and the node snap as build-snap so you can fully focus on the electron side of things:

name: electron-hello-world-kiosk
version: '0.1'
summary: Hello World Electron app for a Kiosk
description: |
  Simple Hello World Electron app as an example of a HTML5 Kiosk
base: core18
confinement: strict
grade: devel
compression: lzo

apps:
  electron-hello-world-kiosk:
    daemon: simple
    extensions: [ gnome-3-28 ]
    restart-condition: always
    command: snap/command-chain/desktop-launch xwayland-kiosk-launch $SNAP/electron-helloworld/electron-quick-start --no-sandbox
    plugs:
      - browser-support
      - network
      - network-bind
      - opengl
      - pulseaudio
      - wayland

layout:
  /usr/share/fonts:
    bind: $SNAP/usr/share/fonts

environment:
  XWAYLAND_FULLSCREEN_WINDOW_HINT: window_role="browser-window"

parts:
  electron-helloworld:
    plugin: nil
    source: https://github.com/electron/electron-quick-start.git
    override-build: |
      npm install electron-packager
      ./node_modules/.bin/electron-packager . --overwrite \
          --platform=linux --output=release-build --prune=true
      cp -v -R ./electron-quick-start-linux-* $SNAPCRAFT_PART_INSTALL/electron-helloworld
    stage-packages:
      - libnspr4
      - libnss3
    build-snaps:
      - node/14/stable

  xwayland-kiosk-helper:
    plugin: cmake
    source: https://github.com/MirServer/xwayland-kiosk-helper.git
    build-packages: [ build-essential ]
    stage-packages: [ xwayland, i3, libegl1-mesa, libgl1-mesa-glx ]
4 Likes
2

Great work, Ogra! Could you make sure all the old tutorials are updated to this new approach?

3

Yup, i’m on it already …

Note though, that I think our long term approach should be to make it seven simpler, integrate all these Xwayland bits into our various extensions and make them respect a snap setting for running in kiosk mode.

I.e. today when packaging an actual wayland app with the gnome extension the only difference between a desktop and a kiosk application is the “daemon” line in snapcraft.yaml.
If we can get the same behavior for X11 apps and make the extension respect a snap setting to launch the app as daemon automatically you would just have to do:

snap install mir-kiosk
snap install eog
snap set eog kiosk=true

… and you got your pictureviewer kiosk up and running …

That will not only make electron packaging even easier but also save users from having to develop their own snap if they just want to “kioskify” an existing application from the store.

4

For policy reasons, we don’t support X11 on Ubuntu Core systems nor with mir-kiosk, only Wayland. That means making "kiosk"s of X11 applications will always need extra work within the snap. (See https://ubuntu.com/tutorials/x11-kiosk.)

In principle, some of that work could be rolled into a snapcraft extension, but would we want to pull an “X11 on Wayland” stack into every X11 application just in case someone wants it as a kiosk?

5

a big chunk of X11 bits are already in the extension anyway to support desktop apps (xkb, xcb, xfixes, xinerama, xrandr, xcursor, fontconfig and libX11 are all in there already).

so all we would need to add to the extension would be a few script changes, xwayland itself and any potential preload libs, that should not be a lot in case you are concerned about the size …

i find the policy argument a little moot as long as we still support you using X11 apps via xwayland on top of mir, we just make it harder for you to do so by forcing you to maintain a separate package (and we just push up our own hosting costs by forcing people into duplicating apps)

6

Xwayland would need a window manager. (But that, and Xwayland could come from a content interface to reduce the impact on size.)

7

The policy prevents applications sharing a single X11 session with all the well rehearsed arguments about the security implications that would have.

[edit]

I meant applications from different snaps. Any isolation of applications within a single snap is the responsibility of the snap author.

8

if that is true, why can something like

work then ? :slight_smile:

9

I’m not sure what that is. Are you saying it provides an X11 session that multiple apps from other snaps can connect to?

I didn’t claim that this is technically impossible, just that it is policy not to do so.

10

no, just a single X11 (kiosk) session that multiple apps shipped inside the snap are sharing, you didnt talk about “other snaps” above :wink: but i get what you mean … in either case that policy doesnt really matter for the “single kiosk app” use case … in fact it supports it wrt greater security IMHO.

12

@ogra Just happened to stumble upon this thread and I figured I’d let you guys know that Electron 12 (released to stable a couple of weeks ago) can now run under Wayland natively, courtesy of Chromium adding support for it upstream. This is the approach I’m currently taking for BeWell’s kiosk snap.

I can’t share a full working snapcraft.yaml file yet at this point, still figuring some things out on our end. But in theory you should now be able to launch Electron apps under Wayland natively (without Xwayland) by adding the following command line arguments:

(…) --enable-features=UseOzonePlatform --ozone-platform=wayland

(In addition to the existing --no-sandbox)

1 Like
13

ohh, thanks a lot for that info, i’ll take a look at it on the weekend !

14

No prob! :slight_smile: By the way, I was wondering: in the example above you’re using the gnome-3-28 extension. Is there any reason you’re not using gnome-3-34 here? It’s more recent and seems to be better documented in the Snapcraft docs.

I’m asking because I’ve been switching between the two today, but the gnome-3-34 extension appears to be throwing me some errors on runtime. Might just be me, but was wondering if you saw the same behavior.

15

yeah, that was exactly my issue too, since 3.28 worked i didnt really bother to dig deeper into teh issues …

1 Like
16

I am keen to know your progress on making a Wayland native snap for electron. Is it possible for you to share your work? Or can I contribute?

Jake

17

Hi @ogra,

Thank you for your example.

I had to add these couple of lines to make the snap build.

       override-build: |
          npm config set scripts-prepend-node-path true
          npm install electron-packager --unsafe-perm=true

Let me know if you can get the a native wayland snap working.
18

Hi Jake! Despite all the bits and pieces seemingly being available now, I couldn’t get this to work immediately and ended up sticking with Xwayland after all for now. It gets the job done!

I feel optimistic that running natively under Wayland should work now, but the cost of figuring it out myself outweighed the benefit of stripping out the relatively small amount of boilerplate left in @ogra’s original post.

19

I noted down my findings (on a Pi4) trying to make electron work as native wayland client (the first link in that post also goes to an updated electron-kiosk source that uses base: core20 and the gnome-3-38 extension with the old XWayland setup) at: