# Imprion PoS - Chromium command-line flags (Doc 1 sect. 6.2).
#
# Debian's /usr/bin/chromium wrapper initialises CHROMIUM_FLAGS="" and then
# sources every file in /etc/chromium.d/ (except README and *.dpkg*) with
# `.`, before `exec /usr/lib/chromium/chromium $CHROMIUM_FLAGS "$@"`.
# This file sorts after the stock fragments (apikeys, default-flags,
# dev-shm, extensions), so it is applied last.
# This is a /bin/sh fragment: append, never assign.

# D7/D10 - Wayland. --ozone-platform-hint=auto makes Chromium pick the
# Wayland backend when WAYLAND_DISPLAY is set (and fall back to X11 only if
# it is not, which on this image means never).
export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --ozone-platform-hint=auto"

# NOT here, deliberately: --enable-wayland-ime (Doc 1 sect. 6.2's second
# flag). It was meant to make the GNOME Shell OSK reach Chromium's form
# fields. QA 2026-09-02 (qa3) measured that it does not buy that: GNOME 48
# never raises the OSK for a Chromium form field, with or without the flag,
# and with or without --enable-features=WaylandTextInputV3 /
# --wayland-text-input-version=3 / --virtual-keyboard - although
# WAYLAND_DEBUG shows Chromium binding zwp_text_input_manager_v3 and
# sending enable/set_content_type/commit, acked by mutter. Decision
# 2026-09-02: the PoS frontend brings its own in-page keyboard, so Chromium
# needs no OSK integration at all and this flag would only be an
# unexercised input-method code path in the browser that runs the till all
# day. GNOME's OSK stays on the image as a manual tool for other
# applications and web pages, raised from the top-bar button in the
# imprion-shell@imprion extension.

# The frontend is started headlessly by pos-frontend.service at login;
# nobody is there to dismiss a first-run bubble. Note that Debian's
# /etc/chromium.d/default-flags already passes --no-default-browser-check,
# so it is deliberately not repeated here.
export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --no-first-run"

# The PoS is a full-screen web application on a fixed-size panel: the frontend
# owns the whole panel, with no tab strip, no address bar and no window
# decoration in the operator's way. Still deliberately NOT --kiosk: D10 keeps
# the desktop reachable, so the shell's overview, the OSK, the a11y menu and
# window controls all stay available for other websites and for support work
# (F11, or the window menu, leaves full screen at any time).
# QA 2026-09-02 (qa3): --start-fullscreen is honoured by chromium 151 on
# Wayland/ozone - verified on the installed image, both after a reboot and
# after `systemctl --user restart pos-frontend`, with the shell top bar
# covered and the tab strip gone.
#
# ...but ONLY for a browser window. This file is sourced by /usr/bin/chromium
# for EVERY Chromium on the terminal, and qa6 measured what that costs: the
# maintenance UI, launched `--app=... --start-maximized` from the top-bar
# Servis button (D-C), came up FULL SCREEN, because --start-fullscreen arrives
# from here and --start-maximized cannot cancel it. A full-screen --app window
# has no title bar, no close button and it covers the top bar, so on a
# touch-only till there was no way back to the PoS short of the overview - and
# D-C's "closing the window returns the operator to the PoS" needs something to
# close. The two kiosk units have the same shape and do not want it either:
# --kiosk already owns the whole output there.
#
# The flag alone does not keep the till full screen: Chromium 154 takes itself
# back out with xdg_toplevel.unset_fullscreen when its start is slow (a boot,
# a RustDesk connection opening while it restarts), and imprion-shell@imprion
# puts it back (decision 270).
#
# So the flag is applied only to a plain browser start. The test reads the
# wrapper's own arguments: /usr/bin/chromium sources /etc/chromium.d/* at line
# 76, well BEFORE it shifts anything off "$@" (its argument loop starts at line
# 94), so the positional parameters here are exactly the ones the caller gave.
case " $* " in
	*" --app="*|*" --app "*|*" --kiosk"*)
		# An --app or --kiosk window sizes itself; leave it alone.
		;;
	*)
		export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --start-fullscreen"
		;;
esac

# QA 2026-09-02: without this, gnome-keyring pops a modal
# "Choose password for new keyring" over the PoS frontend at EVERY Chromium
# start (first boot and every restart-on-crash). Cause: `pos` has a locked
# password (D28), so gdm-autologin's PAM stack cannot unlock a login keyring
# ("gkr-pam: no password is available for user / couldn't unlock the login
# keyring" in the journal) and Chromium's default password store then asks to
# create one. Nobody stands at a till to dismiss it. The managed policy
# already sets PasswordManagerEnabled=false, so the encrypted store buys us
# nothing; `basic` keeps Chromium out of the keyring entirely.
export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --password-store=basic"

# QA 2026-09-02 (screenshot 29): after `pkill chromium` the frontend came back
# with the "Restore pages? Chromium didn't shut down correctly" bubble over the
# PoS. pos-frontend.service restarts Chromium on every crash and on every
# reboot, and the profile is almost always dirty when it does, so that bubble
# would be on the screen most of the time. Verified present in the shipped
# binary: `strings /usr/lib/chromium/chromium | grep -c hide-crash-restore-bubble`
# returns 1 for chromium 151.0.7922.173-1~deb13u1. Chromium still restores
# nothing (the managed policy sets RestoreOnStartup to "open the start-up URLs"),
# it just stops asking.
export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --hide-crash-restore-bubble"
