Files

T

ekklesiaandClaude Opus 5 f65c814eff fix: put the popup close button in the dock, and clear the printer location

Three things, none of them redesigns.

The close affordance for a secondary Chrome window was a separate
layer-shell surface anchored to that window's corner, repositioned by a
five-per-second poll. Any position change tore the surface down and
built another, so on real hardware it chased the window and flickered.
Removed entirely: the GTK button process, the geometry maths that placed
it, the --close-button mode that spawned it, and the poll loop that
drove it. The window helper no longer imports GTK at all.

The behaviour underneath it was right and is kept. The first Chrome
top-level is the classroom browser, tiled and borderless; later ones
float centred at about three quarters of the output. Creation order is
the only thing that can tell them apart — confirmed on a real session,
where every Chrome top-level shares app_id, shell, PID and a null
transient_for, and sway exposes no window properties for Wayland
toplevels at all. Titles are still not used. It now follows sway's own
window events instead of polling, so dragging a popup costs nothing.

Close moved into the dock, which was already on screen and does not
move, so it cannot chase anything. It appears only while a secondary
window is focused and runs kill on that one container. The helper
publishes which window that is; the dock watches the file rather than
polling. A stock sway title bar has no close button, so restoring the
border would not have solved this either.

Two bugs found by looking rather than by testing state. Chrome
renegotiates the size of a popup opened with explicit dimensions after
the resize returns, which left windows centred for a width they no
longer had; placement now settles and repeats once, at creation only, so
dragging is still free. And the dock's Close button came up empty
because show_all does not recurse into a no-show-all widget.

The printer's Location is now blank. CUPS prints it under the queue name
in every dialog, so "Ekklesia Classroom" was a second line the teacher
had to read past; the identity is one word. The already-configured check
includes Location, so a machine set up before this is corrected rather
than left as close enough.

Co-Authored-By: Claude Opus 5 <[email protected]>

2026-09-06 20:24:51 -05:00

7.8 KiB

Raw Blame History

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.

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 only while a secondary window is focused. 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.

7.8 KiB Raw Blame History Unescape Escape