ekklesiaandClaude Opus 5
8ba04801a7
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 <[email protected]>
3.3 KiB
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:
"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.