# Wonder Ink

Wonder Ink is a lesson application, not a browser: its own window, its own
profile, and no way from it into the rest of the web.

Since 0.2.1 it has tabs.

## Why it stopped being Chrome

It used to be `google-chrome --app=https://app.wonderink.org/`. App mode
gives exactly the window a classroom wants — no tab strip, no address bar,
reads as a program — and teacher feedback then found the thing app mode
takes away is the thing they need. A lesson is prepared across several
tabs: the lesson, its video, the activity.

Chrome cannot be asked for "tabs but no omnibox". App mode has no tabs. A
normal window has tabs and an address bar, and no policy, flag or
extension removes the address bar from it. Tabbed web apps come closest,
need a `display_override` in a manifest on a site that is not ours, and
push off-origin links out into a normal browser window — which is the
whole of what this design exists to prevent.

So the tab strip is the classroom's own, in `classroom-wonderink`, and the
engine is Chromium either way.

## Why QtWebEngine

`python3-pyqt6.qtwebengine`, from Debian, updated with the rest of the
system.

The usual and correct objection is codecs, so it was measured before it
was chosen. On Debian 13, QtWebEngine 6.8.2 (Chromium 122):

| | |
| --- | --- |
| `canPlayType` H.264, AAC, MP3, VP8, VP9 | all "probably" |
| `MediaSource.isTypeSupported` avc1, mp4a, vp9 | all true |
| a 720p H.264/AAC file | loaded, played to the end, 1280×720 |
| `app.wonderink.org` | loads; the sign-in is an ordinary email and password form, not a Google flow that would mind an embedded browser |

Two further things the shell does for the same reason:

* **The user agent** has QtWebEngine's own token stripped, leaving a plain
  Chrome string. The engine really is that Chromium, and a site gating on
  the UA should not see something it has never heard of.
* **Widevine** is handed to it from Chrome's own bundle when Chrome is
  installed, which on a classroom machine it always is. A lesson whose
  video service wants DRM is not stopped by the engine change. Absent, the
  flag is not passed and nothing else is affected.

## What a teacher gets

    [ Lesson ] [ Video ] [ Activity ]

The strip appears only when there is more than one tab, so a room with one
lesson open looks exactly like the application this replaced. Each tab has
a close button. Closing the last one closes Wonder Ink; closing any other
leaves the rest alone.

A tab can only come from the lesson: a link the site opens in a new
window, a middle click, a Ctrl+click, "open in a new tab" in the menu.
There is no address bar, no search, and no button that makes a blank tab.
That is the seam the whole design turns on — Wonder Ink can take a teacher
anywhere it needs to, including a video CDN nobody told us about, and a
teacher cannot take themselves anywhere.

**There is deliberately no allowlist of domains.** A list would have to be
right about every service a lesson might ever embed, and the day it is
wrong a teacher is standing in front of a class.

The right-click menu is built rather than filtered, so a future Qt cannot
grow view-source or save-page back into it without somebody noticing in
the code: back, forward, reload, open in a new tab when there is a link,
cut/copy/paste in a text field, print.

Keys: Ctrl+W closes a tab, Alt+Left and Alt+Right navigate, Ctrl+P prints,
Ctrl+Tab switches. Ctrl+T, Ctrl+N and Ctrl+L are deliberately unbound.

## What stayed the same

* **A separate profile from the ordinary browser.** A teacher's Wonder Ink
  sign-in and the room's shared YouTube account are different sessions in
  different storage that cannot reach each other. The browser is still
  Chrome and nothing in this change touches it.
* **Cookies live only as long as the window.** This is what the Chrome
  policy's `CookiesSessionOnlyForUrls` did for wonderink.org, and it is
  the reason closing Wonder Ink ends the teacher's session rather than
  leaving the next person signed in as the last one. The whole profile
  rather than one domain now, because this profile only ever goes where a
  lesson sends it. If a room ever wants sign-ins to survive, it is the one
  line `setPersistentCookiesPolicy` in `classroom-wonderink`.
* **The old Chrome profile is left where it is**, at
  `~/.local/share/ekklesia-classroom/wonderink`. The new one is
  `wonderink-shell` beside it, so rolling back to 0.2.0 finds the old one
  intact.
* **One scale for the room.** Chrome has to be handed `UI_SCALE` because
  it was measured not to follow the compositor on Wayland. Qt does follow
  it — measured at `UI_SCALE=2.0`, where a Qt client on that session
  reports `devicePixelRatio 2.0` without being told anything — so Wonder
  Ink is deliberately *not* told, or the scale would be applied twice.

## Turning it off

One future device is a laptop that will not have Wonder Ink at all.

    WONDERINK_ENABLED=false

in `/etc/ekklesia-classroom/device.conf`, then
`sudo classroom-desktop-layout` and a logout. The launcher comes off the
panel, the command refuses to start and says why, and nothing Wonder Ink
owns runs. The browser, Parent Call and the disc player are untouched, and
the panel stays balanced because the applications are centred rather than
placed.

The setting is read the same way the disc player's line is written: one
marked line in the packaged layout, edited by `classroom-desktop-layout`.
Absent, it means yes — every room that has never heard of the setting is a
room with Wonder Ink.

## Present view video

**Fixed in 0.2.1.** The investigation below is kept because it is what
found the cause, and because the second and third candidates in it were
never ruled out and may still matter.

Candidate 1 — the autoplay gesture chain — is the one the new shell can
act on, and does. Chrome refuses to begin audible playback that no click
asked for, and in Chrome the only lever was `AutoplayAllowlist` on the
policy that governs the ordinary browser as well; allowing autoplay
everywhere on a classroom machine was a real change and was deliberately
not made on a guess.

Wonder Ink is no longer governed by that policy. Its profile is Wonder
Ink and nothing else, so `PlaybackRequiresUserGesture` is turned off for
that profile alone and reaches no other page in the room. The ordinary
browser is a separate application with a separate policy and is not
touched.

Measured both ways in the lab, with a page that starts an *unmuted* video
from a script with no user gesture — which is what Present view does:

| | |
| --- | --- |
| the setting at Chrome's default | `AUTOPLAY BLOCKED: NotAllowedError` — the exact error predicted below |
| the setting as shipped | `AUTOPLAY OK muted=false`, video playing |

That is the lab reproducing the failure and then not reproducing it. It
is **not** confirmation that Present view itself is fixed, because the
lab has no Wonder Ink account: if Present view still stops after this,
candidates 2 and 3 below are where to look next.

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

*Since 0.2.1 this no longer applies to Wonder Ink, which is not a Chrome
window any more and allows its own lesson to start a video without
changing anything about the browser. See the top of this section. It
still applies to the ordinary browser, where nothing has changed.*

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