Add Chromium as an opt-in browser engine (Luakit/WebKitGTK hard-hangs on Intel Iris Xe)

[aaronmayeux]

Summary

On Intel Iris Xe (Gen12) hardware, Luakit's WebKitGTK threaded compositor
reliably hard-hangs the GPU — the kernel logs an i915 GPU HANG (with GuC
reset failures) and the display freezes. No Luakit/WebKit setting I tried
avoids it. The add-on is otherwise ideal for a wall panel, so rather than drop
it I added an opt-in Chromium engine and have been running it permanently
on a 43" panel. I'd like to contribute it back, but want your steer on a couple
of approach questions first.

What I built (backward-compatible; default unchanged)

• New browser option: luakit (default) or chromium. Existing installs are
  unaffected.
• Chromium launches in --kiosk on X11/Ozone and is controlled over the
  DevTools protocol (CDP): launch_url → Page.navigate, refresh_browser →
  Page.reload. The Luakit -n/xdotool paths are untouched.
• cdp_auth.py — self-healing login: if Chromium lands on the HA login page it
  mints a token over the trusted loopback and injects it, then loads the
  dashboard (no-op once the profile is authed).
• kiosk_overlay.py — injects an always-visible in-page "back to dashboard"
  button on kiosk-out pages (games, external Maps/Earth), composited over CDP so
  it works on third-party pages too.
• A Chromium managed policy to suppress the first-run "Sign in to Chromium" nag.
• README / CHANGELOG / translations updated.

Tested on

Beelink EQi12 (i5-1235U, Iris Xe), HAOS, 43" touch panel — boot → dashboard,
live WebRTC/H.264 cameras, touch gestures, screen-off, survives add-on restart
(persistent profile). I can attach the full i915 GPU HANG dmesg/journal from
the Luakit failure if useful.

Two questions before I open the PR

1. Install strategy. I bake Chromium at image-build time behind a
   BUILD_BROWSER build-arg, so the default Luakit image stays identical and
   Chromium is only present when explicitly built. Would you prefer that, or a
   runtime first-boot apk add chromium so one published image serves both?

2. Auth. The hands-off login currently relies on the trusted_networks
   provider trusting loopback (token-inject). The more universal alternative is
   a username/password CDP form-fill that works without trusted_networks
   but is more brittle across HA login-page changes. For upstream, would you
   rather I (a) just document trusted_networks as the requirement,
   (b) implement the form-fill fallback, or (c) both?

The branch is ready off your testing branch:
aaronmayeux/HAOS-kiosk:feat/chromium-browser-option. Happy to adjust to your
preferences and open the PR.

[YogatBear]

Thank you so much for this! I just tried your branch as I have been having issues with luakit, and it solved all of my problems, including:

• Touch issue with sliders #56 as it is specifically a luakit issue
• Stuttering when using WallPanel screen saver
• Some additional luakit crashes that require a refresh to display the dashboard again

It does seem to use more ram, but for a 4GB rPi it is negligable and runs very smooth.

[taucher4000]

This sounds great. Hope this MR can make it into the project 👍

[puterboy]

I am working on a modular approach that will allow you to choose your browser.
I am concerned about people with Pi3's or with people who have other heavy stuff running and don't need full chromium browser RAM - which also tends to grow :)