Kiosk mode

[ethanjli]

We will need to figure out a way to run the web browser (Firefox ESR 68.9.0) in kiosk mode, so that the browser starts in full-screen mode with a URL of our choosing. We will also need to figure out how we might prevent the user from exiting kiosk mode, as well as how to disable the panels (but in a way that we can re-enable them during development).

Ideally we would also be able to disable various UI elements we might not want (e.g. right-click context menu, swipe gestures for going backwards/forwards if the browser naturally picks up those swipe gestures, etc.). It'd also be great if we could minimize the number of extensions loaded, including any extensions which come with Firefox by default - maybe some of these configurations would be saved in a user profile which we could copy onto the filesystem from our deploy script?

Additionally, if Firefox crashes, we want to suppress any "bug reporting" pop-up windows.

[ethanjli]

It turns out that Firefox ESR does not have kiosk mode, so we'll need to find another alternative to Firefox ESR. Here are some options to try out on the Raspberry Pi, in order of increasing estimated difficulty:

• Installing a Firefox extension which might give a kiosk mode - e.g. https://addons.mozilla.org/en-US/firefox/addon/modern-kiosk/ ?
• Trying out any of the other browsers available for RPi - e.g. GNOME Web/Epiphany, Midori, Qutebrowser, GNU Icecat - and seeing if 1) any supports kiosk mode, and 2) the frontend runs in them at all
• Creating a simple Python script or C++ program which embeds a web browser rendering engine as a widget in a fullscreen window - e.g. through Qt's WebKit widget, wxWebConnect, pywebview, cefpython, etc.
• Installing the post-71 (i.e. non-ESR) version of Firefox on the RPi - I'm not sure if this is easy/possible
• Seeing if we can optimize the frontend's graph plotting performance enough that if we add another waveform (for a total of 3 waveforms) and switch to Chromium, the frontend would still run at acceptable speed

[ethanjli]

Because I needed to reinstall Firefox ESR on my Raspberry Pi, I decided to install a few other browsers in the package manager so I (re-)tested the following browsers:

• Midori, Epiphany (preliminary Google searches suggest they have kiosk mode), surf-display (this is a kiosk mode web browser): all totally mess up the rendering, and the WebSocket connection to the backend doesn't work. They all use WebkitGTK, so from these tests I think we can probably rule out any browser using the system's default installation of WebkitGTK.
• qutebrowser: I was not able to install the modern rendering engine (QtWebEngine) due to missing dependencies; instead I could only install the QtWebKit backend, which was not able to load the frontend at all.

So I think we can rule out trying to install any other "standard" web browsers.

[ethanjli]

I just did some quick experiments:

• I couldn't get pywebview to work
• cefpython is not available for ARM architectures such as the Raspberry Pi
• When I downloaded the "Sample Application" build of CEF (Chromium Embedded Framework) for Linux ARM and ran the "cefsimple" application, I was able to get it to run what is almost a kiosk mode browser showing just our frontend page (the only thing missing is fullscreen). However, rendering framerate with the live plots was not actually *worse than in regular Chromium despite having less "extra code" bundled in; perhaps Chromium built for the RPi has some special optimizations.
• It looks like QtWebEngine is not available for Raspberry Pi

I once again reviewed the CPU usage pattern in Chromium, and it looks like CPU usage is only unacceptably high after there are a lot of points to replot on the screen (i.e. the waveform is at the right end of the plot). This suggests that it may be possible to optimize plotting in a way I had previously thought of (essentially splitting the waveform into smaller separate-but-overlapping segments, so that only the newest segment needs to be redrawn); and it may be acceptable to redraw at a lower framerate but add a segment of points on each redraw, instead of redrawing upon every new point. With these optimizations, it should be possible to support 2 live plots smoothly in Google Chrome, but I think only experimentation will let us determine whether we can support 3 live plots smoothly in Google Chrome which would be needed for the V2 UI design.

[ethanjli]

According to this forum post, Firefox 71 is available on Ubuntu for the Raspberry Pi: https://www.raspberrypi.org/forums/viewtopic.php?p=1602724#p1602724 . If it turns out that there is no way we can get Chromium to have acceptable performance, this could be a reasonable backup option - but switching to Ubuntu might be a very drastic change from the perspective of OS/deployment configuration so I think that is the last resort.

[ethanjli]

I tried the Modern Kiosk extensions for Firefox very briefly. It does make a Kiosk mode, but it doesn't/can't autostart in kiosk mode, so it's a no-go.