ekklesiaandClaude Opus 5
0e91b4cbd3
The Close button followed focus, and moving the pointer down to the dock moves focus off the popup. So the button disappeared somewhere on the journey to it, and a secondary Chrome window could not be closed with a mouse at all. Found on the endpoint; my fault. The target is remembered instead. Once a secondary window has been focused the dock keeps offering to close it, and losing focus — to the dock, the main browser, a print dialog, any layer-shell surface — changes nothing. It moves on only when that window closes or another secondary takes over, and it falls back to another open secondary rather than to nothing, so cancelling a print dialog leaves the render window still closeable. It is chosen from the secondary list, which never contains the first window, so it can never name the main browser. Restoring the floating role to a window that already existed no longer moves or focuses it. Moving it would undo wherever the teacher dragged it; focusing it would raise the render window over the print dialog sitting above it, which is one way the print flow was getting disturbed. Verified by driving a real pointer through the exact path that was broken: pointer over the popup, click to focus, then travel down to the dock in steps, screenshotting throughout. The button is still there on arrival, at 992,1041. Then the print flow: main browser, render window and a separate Print dialog, pointer to the dock, button still there, and killing the dialog leaves the render window as the new target with the main browser untouched. The button's own action could not be actuated in that harness, because synthetic pointer input does not reach Wayland clients under headless sway — the Browser button does not respond to it either. The action was run directly instead, closing exactly the remembered container and leaving main Chrome alive. Co-Authored-By: Claude Opus 5 <[email protected]>
192 lines
8.6 KiB
Markdown
192 lines
8.6 KiB
Markdown
# 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.
|