# The classroom browser

A classroom computer is a shared appliance, not somebody's laptop. There
is **one local Chrome profile**, owned by the room. Teachers sign into
*websites*; nobody signs into *Chrome*.

## Policies

All of these are in
`/etc/opt/chrome/policies/managed/ekklesia-classroom.json`, and every
name was checked against the strings of the installed Chrome 152 binary
with deliberately invalid names as a control.

| Policy | Value | Why |
| --- | --- | --- |
| `BrowserSignin` | `0` | Chrome never asks who is using it |
| `SyncDisabled` | `true` | Explicit, though `BrowserSignin: 0` implies it |
| `SigninInterceptionEnabled` | `false` | No "this account is managed" bubble |
| `BrowserAddPersonEnabled` | `false` | No new Chrome profiles |
| `BrowserGuestModeEnabled` | `false` | Removes the Guest entry point from the profile menu |
| `ProfilePickerOnStartupAvailability` | `1` | No profile picker at startup |
| `PasswordManagerEnabled` | `false` | No offers to save passwords |
| `PasswordLeakDetectionEnabled` | `false` | No leak warnings |
| `BackgroundModeEnabled` | `false` | Closing the last window really ends the session |
| `CookiesSessionOnlyForUrls` | `["[*.]wonderink.org"]` | Wonder Ink should not outlive a teacher |
| `DefaultBrowserSettingEnabled` | `false` | No default-browser prompt |
| `PromotionalTabsEnabled` | `false` | No welcome tabs |
| `MetricsReportingEnabled` | `false` | — |
| `ShowHomeButton` | `true` | One obvious way back |
| `HomepageLocation` | Wonder Ink | — |
| `HomepageIsNewTabPage` | `false` | — |

`BrowserGuestModeEnabled: false` is the answer to "other profile
switching entry points". Guest mode is the one that survives
`BrowserAddPersonEnabled: false`, and disabling it is the supported
mechanism — no UI hacks. Guest mode is **not** used as the browsing
model: the room needs one persistent profile so the church YouTube login
survives.

None of this touches website logins. Wonder Ink, Google and YouTube
sign-ins are ordinary site sessions and are unaffected by
`BrowserSignin: 0`, which governs signing in to the *browser*.

## Secondary Chrome windows

Chrome gives the main browser and additional top-level windows the same
`google-chrome` app ID, the same browser PID, and no reliable distinguishing
properties. Page titles are site content and are deliberately not used.

`classroom-chrome-windows` follows the Sway tree during the session and assigns
roles by creation order:

- the first Chrome top-level is the main classroom browser and remains tiled,
  maximised and borderless;
- every later Chrome top-level floats at 76% of the logical workspace, centred
  above the main browser;
- a red **Close ×** button is placed at its top-right and kills only that
  secondary container;
- when the secondary closes, the still-tiled main browser underneath has not
  been moved or resized.

The Sway `for_window` rule still only removes Chrome borders. There is no broad
Chrome floating rule: the session helper issues commands against the exact
`con_id` of each additional container. If the main window is closed first, the
oldest remaining Chrome window is promoted back to the tiled, borderless main
role.

## What the policies do not remove

The avatar button stays in the toolbar. Verified by screenshotting
Chrome with these policies applied and comparing against Chrome without
them: the button is in the same place either way.

What changes is what is behind it. Sign-in, adding a profile and Guest
mode are all disabled by policy, so the menu has nothing left that
creates or switches a profile. Chrome 152 has no policy that removes the
button itself — `ProfileSwitcherEnabled` and similar names do not exist,
checked against the binary — and hiding it would mean the UI hacks this
is meant to avoid.

Worth a look at the endpoint: open that menu once and confirm it offers
nothing actionable.

## Wonder Ink between teachers — CONFIRMED WORKING

Teacher A signs in, uses the room, Chrome closes, teacher B opens Chrome
and Wonder Ink is signed out, while YouTube stays signed into the church
account.

`CookiesSessionOnlyForUrls` with `[*.]wonderink.org` does it. That
pattern covers `app.wonderink.org` and every other subdomain.

**Confirmed on the physical endpoint**, which is the only place it could
be: it needs a real Wonder Ink login. It could not be established here,
and three attempts to prove the mechanism against a local test site were
inconclusive because the positive control never worked — so this was
shipped as unverified and the endpoint settled it.

Two consequences worth keeping in mind.

Wonder Ink's session is therefore **in cookies**, not in `localStorage`.
That matters because there is no per-site Chrome policy that clears
localStorage on exit: `ClearBrowsingDataOnExitList` and
`BrowsingDataLifetime` both exist in Chrome 152 but are global, and
blanket clearing would take YouTube with it. Had it gone the other way,
this would have needed a classroom-owned cleanup instead.

### If Wonder Ink login is "Sign in with Google"

`app.wonderink.org` loads Google Identity Services
(`accounts.google.com/gsi/client`), so Google sign-in is at least
offered.

If teachers sign into Wonder Ink *through Google*, clearing
`wonderink.org` will sign them out of Wonder Ink — but the Google
session at `accounts.google.com` is deliberately kept, because that is
what keeps YouTube Premium signed in. The next teacher could then be one
click from re-entering the previous teacher's Wonder Ink account.

These two requirements genuinely conflict, and which one applies depends
on how teachers actually sign in. Worth knowing before Sunday. If
teachers use Wonder Ink email-and-password accounts, there is no
conflict at all.


## Extra browser windows

The first Chrome top-level window is the classroom browser: tiled,
borderless, filling the desktop above the dock. Every later Chrome
top-level floats instead — centred, about three quarters of the output,
borderless — so it sits over the browser rather than tiling beside it
and shoving the lesson to half width.

Which window is which can only be creation order. Verified on a real
session: every Chrome top-level has the same `app_id`, the same
`shell=xdg_shell`, the same PID, a null `transient_for`, and sway
exposes no `window_properties`, `window_role` or `window_type` for
Wayland toplevels at all. Page titles are deliberately not used.

`classroom-chrome-windows` follows sway's own window events rather than
polling, so dragging a popup costs nothing.

### Closing one

The Close button is **in the dock**, and it is **sticky**. Once a
secondary window has been focused, the dock keeps offering to close it
until that window goes away.

That stickiness is the whole design. It first followed focus, which made
the button impossible to click: moving the pointer down to the dock
moves focus off the popup, so the button vanished somewhere on the way
to it. Nobody could ever reach it.

The remembered target changes only when:

- the window it names closes — and it then falls back to another
  secondary that is still open, so cancelling a print dialog leaves the
  render window still closeable; or
- another secondary window is focused and takes over.

Focus moving to the dock, the main browser, a print dialog or any
layer-shell surface changes nothing. The target can never be the main
browser: it is chosen from the secondary list, which never contains the
first window.

Clicking it runs `[con_id=N] kill` on that exact container: never the
main browser, never a Chrome process.

An earlier attempt anchored a close button to the popup's own corner as
a separate layer-shell surface. On real hardware it chased the window
and flickered, because every position change meant tearing a surface
down and building another. The dock does not move, so it cannot chase
anything.

Note that a stock sway title bar has no close button, so putting the
border back would not have solved closing either.

### Printing

A site's own Print button opens a Chrome window to render the document
and then a print dialog on top of it. Verified in a real session: that
is **three** top-level windows — the browser, the render window, and a
separate `"Print"` dialog — and the render window is
indistinguishable from a genuine popup by anything except its title.

No special case was added, because there is no signal to special-case
on. The generic treatment already produces the right result: the render
window and the print dialog both float centred and borderless over an
untouched main browser, the dialog is the obvious foreground window, and
anything left behind is one dock click away. The render window used to
be the one thing on screen wearing a sway title bar; it no longer is.