# 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.