From 8ba04801a76ee599c7fa40a6407e555a3ea0c0e5 Mon Sep 17 00:00:00 2001 From: ekklesia Date: Sat, 5 Sep 2026 00:21:18 -0500 Subject: [PATCH] docs: record the Wonder Ink Present view observation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Vimeo plays in the normal lesson view and stops immediately in Present view, which rules the machine out: same video, same host, same codecs, a click earlier. No packages were installed and nothing was changed. Written as a decision procedure rather than a shrug. The first step is a stock Chrome with no classroom policy and a clean profile, which settles in one run whether this is Wonder Ink or something at our end. Two candidates follow if it turns out to be ours, each with the diagnostic that would confirm it, and the note that AutoplayAllowlist is recognised by Chrome 152 but has deliberately not been applied — allowing autoplay on a classroom machine should follow evidence rather than a guess. Co-Authored-By: Claude Opus 5 --- docs/testing.md | 14 ++++++ docs/wonder-ink.md | 104 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 118 insertions(+) create mode 100644 docs/wonder-ink.md diff --git a/docs/testing.md b/docs/testing.md index 3973148..1132d09 100644 --- a/docs/testing.md +++ b/docs/testing.md @@ -63,6 +63,20 @@ into separate layer-shell windows. - [ ] The Home button returns to Wonder Ink - [ ] Fullscreen YouTube video uses the whole display - [ ] Leaving fullscreen restores the correct geometry above the dock +- [ ] Chrome has **no sway title bar** — the window starts at Chrome's + own tab strip, and Chrome's tabs and address bar are still there +- [ ] Chrome still maximises and minimises as before +- [ ] After a reboot, no "Restore pages? Chrome didn't shut down + correctly" bubble +- [ ] Chrome does not offer to save passwords +- [ ] `chrome://policy` lists PasswordManagerEnabled as an applied + managed policy +- [ ] Website logins still persist across a reboot +- [ ] Clicking Browser when Chrome is closed shows a throbber on the + dock button until the window appears +- [ ] Clicking Browser when Chrome is already open feels immediate, + with no throbber +- [ ] The pointer shows a busy cursor while it is over the dock - [ ] No first-run, default-browser or sign-in nag appears - [ ] `chrome://policy` lists the Ekklesia policies as applied, with no "unknown policy" entries diff --git a/docs/wonder-ink.md b/docs/wonder-ink.md new file mode 100644 index 0000000..ed13125 --- /dev/null +++ b/docs/wonder-ink.md @@ -0,0 +1,104 @@ +# Wonder Ink: Present view video + +## The observation + +On the classroom endpoint: + +- Vimeo videos embedded in Wonder Ink **play correctly** in the normal + lesson view. +- The **same** videos in Wonder Ink's **Present** view stop immediately + when Play is pressed. + +## What this rules out + +The system's video capability is fine. The same video, the same host, +the same browser and the same codecs work a click earlier in the same +session. Nothing is missing from the machine. + +**No codecs or media packages were installed for this, and none should +be.** Installing packages to fix a problem that is not a missing package +would leave the classroom carrying software it does not need, and would +not fix Present view. + +Nothing in the system was changed for this. + +## The decisive test + +Run it once at the endpoint. This separates "Wonder Ink" from "the +classroom's Chrome configuration" in one step: + +``` +sudo mv /etc/opt/chrome/policies /etc/opt/chrome/policies.off +google-chrome --user-data-dir=/tmp/plain-chrome +``` + +That is a stock Chrome with a clean profile and no classroom policy at +all. Sign in, open the lesson, press Present, press Play. + +- **Still fails** — it is Wonder Ink, and nothing here can fix it. + Report it to them with the console output below. +- **Works** — something in the classroom configuration is responsible, + and the next section is where to look. + +Afterwards: + +``` +sudo mv /etc/opt/chrome/policies.off /etc/opt/chrome/policies +rm -rf /tmp/plain-chrome +``` + +## If it turns out to be this end + +Two candidates, in order of likelihood. **Neither has been applied.** + +### 1. The autoplay gesture chain + +Chrome refuses to start audible playback without a user gesture. If +Present view starts the player programmatically after its own view +transition, the gesture from the Present click may not carry, and +Chrome rejects the play. That would look exactly like this: fine when +you click the player directly, dead when the view starts it for you. + +This is stock Chrome behaviour, not a classroom setting — a plain Chrome +on any machine would do the same, which is what the decisive test above +checks. + +Diagnostic: open DevTools (F12) in Present view and press Play. A +rejected autoplay logs: + +``` +NotAllowedError: play() failed because the user didn't interact +with the document first. +``` + +If that appears, the fix is a scoped policy, not a global one: + +```json +"AutoplayAllowlist": ["https://app.wonderink.org"] +``` + +`AutoplayAllowlist` is recognised by Chrome 152 — verified against the +installed binary. It has deliberately **not** been added, because +allowing autoplay everywhere on a classroom machine is a real change and +should follow evidence, not a guess. + +### 2. A popup window that sway tiles + +sway tiles new windows rather than floating them. If Present view opens +a second browser window, it gets a tiled geometry the site did not +expect, and a player that is resized or re-parented mid-start can stop. + +Diagnostic, while Present view is open: + +``` +swaymsg -t get_tree | grep -c google-chrome +``` + +More than one Chrome window means this is worth pursuing. + +### 3. Not the classroom policies + +For completeness, so nobody re-audits them: the managed policy in +`/etc/opt/chrome/policies/managed/` sets first-run, sign-in, password +and homepage behaviour only. None of it touches media, autoplay, +iframes, fullscreen or site permissions.