@gjsify/adwaita-web 0.41.0 → 0.42.0

package/src/elements/adw-view-switcher-bar.ts

@@ -24,6 +24,7 @@ import { ViewSwitcherBarState, buildViewSwitcherButtons, viewSwitcherPagesFromSt
 import type { AdwViewStack } from './adw-view-stack.js';
 import { applyDescription, applyIndicator, applySwitcherIcon } from './view-switcher-dom.js';
 import { type AdwIcon, createAdwIcon } from './adw-icon.js';
+import { attachRovingFocus } from './roving-focus.js';
 
 /** The DOM nodes one bar button owns — the bar paints the derived model onto them. */
 interface BarButtonNodes {
@@ -88,6 +89,20 @@ export class AdwViewSwitcherBar extends HTMLElement {
             this._barEl.className = 'adw-view-switcher-bar-box';
             this._barEl.setAttribute('role', 'tablist');
             this.replaceChildren(this._barEl);
+            // What makes the roving tabindex below navigable: without it the unselected
+            // buttons are reachable by no key at all.
+            attachRovingFocus({
+                host: this,
+                orientation: 'horizontal',
+                items: () => this._nodes.map((nodes) => nodes.button).filter((button) => !button.hidden),
+                select: (item) => {
+                    const stack = this._stack;
+                    if (!stack) return;
+                    const index = Number(item.dataset.pageIndex);
+                    // Re-assigning the current index would re-run the stack's transition.
+                    if (stack.visibleChildIndex !== index) stack.visibleChildIndex = index;
+                },
+            });
         }
         this._barState.setReveal(this._readReveal());
 
@@ -208,6 +223,9 @@ export class AdwViewSwitcherBar extends HTMLElement {
         button.type = 'button';
         button.className = 'adw-view-switcher-bar-button';
         button.setAttribute('role', 'tab');
+        // The page index, so a keyboard move resolves an item back to a page without
+        // recomputing the mapping — the spelling `<adw-inline-view-switcher>` uses.
+        button.dataset.pageIndex = String(pageIndex);
 
         const icon = createAdwIcon(null, 'adw-view-switcher-bar-icon');
 

package/src/elements/adw-view-switcher.ts

@@ -55,6 +55,7 @@ import {
     readSwitcherPage,
 } from './view-switcher-dom.js';
 import { type AdwIcon, createAdwIcon } from './adw-icon.js';
+import { attachRovingFocus } from './roving-focus.js';
 
 /** The DOM nodes one page owns — the switcher paints the derived model onto them. */
 interface PageNodes {
@@ -171,6 +172,16 @@ export class AdwViewSwitcher extends HTMLElement {
         this._barEl = document.createElement('div');
         this._barEl.className = 'adw-view-switcher-bar';
         this._barEl.setAttribute('role', 'tablist');
+        // What makes the roving tabindex below navigable: without it the unselected
+        // buttons are reachable by no key at all.
+        attachRovingFocus({
+            host: this,
+            orientation: 'horizontal',
+            items: () => this._nodes.map((nodes) => nodes.button).filter((button) => !button.hidden),
+            select: (item) => {
+                this._state.setSelected(Number(item.dataset.pageIndex));
+            },
+        });
 
         this._contentEl = document.createElement('div');
         this._contentEl.className = 'adw-view-switcher-content';
@@ -254,6 +265,9 @@ export class AdwViewSwitcher extends HTMLElement {
         button.type = 'button';
         button.className = 'adw-view-switcher-button';
         button.setAttribute('role', 'tab');
+        // The page index, so a keyboard move resolves an item back to a page without
+        // recomputing the mapping — the spelling `<adw-inline-view-switcher>` uses.
+        button.dataset.pageIndex = String(index);
 
         // Both children always exist, as in AdwViewSwitcherButton's template — the icon
         // carries `image-missing` rather than disappearing.

package/src/elements/modal-surface.ts

@@ -0,0 +1,180 @@
+// The one focus trap behind every `aria-modal="true"` surface in this package.
+//
+// THE INCIDENT
+//
+// Four elements set `aria-modal="true"`. One of them honoured it. Measured in Firefox
+// on a page whose next tabbable element was a view-switcher button: focus the last
+// control inside `<adw-alert-dialog>`, press Tab once, and focus landed on
+// `.adw-view-switcher-bar-button` — outside the dialog, behind its own scrim, on a
+// control the user cannot see. `<adw-about-dialog>` and `<adw-preferences-dialog>` did
+// the same. Closing the dialog then left focus there: none of the three returned it to
+// whatever opened them, so a keyboard user finished the interaction somewhere they never
+// asked to be. `aria-modal` tells assistive technology the rest of the page is inert; it
+// changes NOTHING about where the browser sends Tab. Only `<adw-dialog>` implemented the
+// half that is not free, and this module is that half, lifted out of it verbatim.
+//
+// WHY IT IS A MODULE AND NOT A COPY
+//
+// `aria-modal` — the attribute and the reflected `.ariaModal` property alike — now lives
+// HERE and nowhere else, held by the `[trap]` arm of
+// `scripts/check-adwaita-keyboard-contract.mjs`. That is what makes a fifth modal surface
+// impossible to add without a trap: the declaration and the behaviour it promises are
+// the same call.
+//
+// Reference: refs/libadwaita/src/adw-dialog.c — GTK_ACCESSIBLE_ROLE_DIALOG (:1290) and
+// the dialog's own focus handling, which cannot leave the widget because GTK confines
+// focus to the presented dialog by construction. The DOM has no such confinement, so it
+// is spelled out.
+// Reference: refs/libadwaita/src/adw-alert-dialog.c:1103 — GTK_ACCESSIBLE_ROLE_ALERT_DIALOG.
+// Reference: https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/ — the Tab/Shift+Tab
+// wrap and the return-focus rule, for the part upstream leaves to the platform.
+
+/**
+ * Everything the browser will hand focus to on Tab. `[tabindex="-1"]` is excluded
+ * deliberately: it is programmatically focusable and NOT in the tab order, so treating
+ * it as a trap boundary would make Tab stop on a scrim.
+ */
+const FOCUSABLE_SELECTOR = [
+    'a[href]',
+    'button:not([disabled])',
+    'input:not([disabled])',
+    'select:not([disabled])',
+    'textarea:not([disabled])',
+    '[tabindex]:not([tabindex="-1"])',
+].join(',');
+
+/** The two roles a modal surface in this package declares. */
+export type AdwModalRole = 'dialog' | 'alertdialog';
+
+export interface AdwModalSurfaceInit {
+    /**
+     * The custom element itself. It receives the keydown listener, because a dialog that
+     * moves focus to its HOST — `<adw-preferences-dialog>` does — would otherwise press
+     * Tab against a listener on a descendant that never sees the event.
+     */
+    host: HTMLElement;
+    /** The element carrying the role, `aria-modal`, and the boundary focus may not cross. */
+    surface: HTMLElement;
+    /** The WAI-ARIA role for {@link AdwModalSurfaceInit.surface}. */
+    role: AdwModalRole;
+    /** Whether the dialog is presented right now. */
+    isOpen: () => boolean;
+    /** Escape while open. Dismissal is the element's own business (`can-close`, close-response). */
+    onEscape: () => void;
+    /**
+     * Where focus goes on present, when the element wants something other than the first
+     * focusable control — `<adw-alert-dialog>` starts on its DEFAULT response, not on the
+     * leftmost button. It is handed {@link AdwModalSurface.focusables}, so a rule like
+     * "the first control in the content area" is a `find` over that list rather than a
+     * second copy of the filter.
+     *
+     * Returning nothing — or an element that is not in that list — falls back to the
+     * first focusable, then to the surface itself.
+     */
+    initialFocus?: (focusables: readonly HTMLElement[]) => HTMLElement | null | undefined;
+}
+
+/**
+ * A modal surface: it declares `aria-modal`, keeps Tab inside itself, and gives focus
+ * back to whatever had it when the dialog appeared.
+ *
+ * The element drives it with two calls — {@link present} when it opens and
+ * {@link dismiss} when it closes — and keeps its own dismissal rules.
+ */
+export class AdwModalSurface {
+    private readonly _init: AdwModalSurfaceInit;
+    /** Focused before `present()`, restored by `dismiss()`. */
+    private _previouslyFocused: HTMLElement | null = null;
+
+    constructor(init: AdwModalSurfaceInit) {
+        this._init = init;
+        init.surface.setAttribute('role', init.role);
+        init.surface.setAttribute('aria-modal', 'true');
+        // The surface is the fallback focus target, so it has to be able to hold focus
+        // even when it contains no control at all. Not in the tab order: -1.
+        if (!init.surface.hasAttribute('tabindex')) init.surface.tabIndex = -1;
+        init.host.addEventListener('keydown', (event) => this._onKeyDown(event));
+    }
+
+    /** The controls inside the surface, in tab order, that a `focus()` can actually reach. */
+    focusables(): HTMLElement[] {
+        return Array.from(this._init.surface.querySelectorAll<HTMLElement>(FOCUSABLE_SELECTOR)).filter(
+            // `getClientRects()` and not `hidden`: `<adw-about-dialog>` keeps every
+            // navigation page in the DOM and shows one, so the non-visible pages'
+            // buttons match the selector, are not `[hidden]`, and cannot take focus.
+            // Tabbing onto one silently leaves focus where it was — a trap that lets go.
+            (el) => !el.hasAttribute('disabled') && !el.hidden && el.getClientRects().length > 0,
+        );
+    }
+
+    /**
+     * Remember where focus was, then move it inside.
+     *
+     * SYNCHRONOUS, and that was measured rather than assumed. `<adw-about-dialog>` used to
+     * defer this by a `requestAnimationFrame`, which reads as "the sheet is not laid out
+     * yet" — it is not. Every element here toggles its `open` class before calling this,
+     * so the surface is already displayed; reading `document.activeElement` in the same
+     * task that sets `open` finds it inside the dialog for all four. A retry frame would
+     * be a branch nothing can reach, and a spec asserting focus one frame late would pass
+     * over a dialog that never focused anything at all.
+     */
+    present(): void {
+        const active = document.activeElement;
+        this._previouslyFocused = active instanceof HTMLElement && active !== this._init.host ? active : null;
+        const focusables = this.focusables();
+        // A `??` chain falls through when the element asks for NOTHING, never when it asks
+        // for something the browser refuses — so a request is honoured only if it is in the
+        // list, the same test the trap uses for its edges. Measured in Firefox before this
+        // filter: an `<adw-alert-dialog>` whose default response was DISABLED handed that
+        // button back, `focus()` on it was a no-op, and the dialog opened with
+        // `document.activeElement` still on the opener OUTSIDE it. The keydown listener
+        // sits on the host, so focus never entered, no key ever reached the trap, and a
+        // real Escape left `open` true — unreachable and undismissable at once.
+        const wanted = this._init.initialFocus?.(focusables);
+        const target =
+            (wanted && focusables.includes(wanted) ? wanted : undefined) ?? focusables[0] ?? this._init.surface;
+        target.focus();
+    }
+
+    /** Give focus back to whatever had it before `present()`. */
+    dismiss(): void {
+        const restore = this._previouslyFocused;
+        this._previouslyFocused = null;
+        if (restore && restore.isConnected) restore.focus();
+    }
+
+    private _onKeyDown(event: KeyboardEvent): void {
+        if (!this._init.isOpen()) return;
+        if (event.key === 'Escape') {
+            event.stopPropagation();
+            this._init.onEscape();
+            return;
+        }
+        if (event.key !== 'Tab') return;
+
+        // The INNERMOST open surface owns Tab: a dialog presented from inside another one
+        // bubbles its keydown to the outer host, which would re-run this wrap against its
+        // own edges and undo the move that just happened.
+        event.stopPropagation();
+
+        const focusables = this.focusables();
+        if (focusables.length === 0) {
+            // Nothing tabbable inside — Tab would leave immediately, so it goes nowhere.
+            event.preventDefault();
+            this._init.surface.focus();
+            return;
+        }
+        const first = focusables[0];
+        const last = focusables[focusables.length - 1];
+        const active = document.activeElement;
+        // The wrap is asserted at the EDGES only: in between, the browser's own tab order
+        // is already correct and intercepting it would break Shift+Tab through a form.
+        if (event.shiftKey && (active === first || active === this._init.surface || active === this._init.host)) {
+            event.preventDefault();
+            last.focus();
+        } else if (!event.shiftKey && (active === last || active === this._init.host)) {
+            event.preventDefault();
+            first.focus();
+        }
+    }
+}

package/src/elements/roving-focus.ts

@@ -0,0 +1,154 @@
+// Arrow-key movement for the composites that hand out a roving tabindex.
+//
+// THE INCIDENT
+//
+// `<adw-view-switcher>`, `<adw-view-switcher-bar>`, `<adw-inline-view-switcher>` and
+// `<adw-sidebar>` each declared `role="tablist"` or `role="listbox"`, then set
+// `tabIndex = -1` on every item except the selected one — the roving tabindex — and
+// registered no keydown listener at all. Measured in Firefox: three items, tabIndex
+// `[0, -1, -1]`, and ArrowRight, ArrowLeft, ArrowDown, Home and End all left
+// `document.activeElement` exactly where it was. The two unselected items were reachable
+// by NO key: the roving tabindex had taken them out of the Tab order and nothing had put
+// them back. That is strictly worse than the plain tab stops they replaced — the widget
+// went from clumsy to unusable by adding an accessibility feature half of it.
+//
+// The rule this module implements is the one `<adw-tab-view>` already states in its own
+// header: "the roving tabindex must keep moving: under `role=tablist` a frozen one leaves
+// every inactive tab keyboard-unreachable". `<adw-tab-view>` keeps its own handler — it
+// also owns Ctrl+Tab, Ctrl+Page-Up/Down and Alt+digit from `Adw.TabView`'s shortcut table,
+// plus a strip-local scroll a shared helper has no business knowing about.
+//
+// WHAT THE KEYS DO, and where each behaviour comes from
+//
+// The SHAPE — Tab enters and leaves at the active item, arrows travel inside — is what
+// the C establishes:
+//   - `refs/libadwaita/src/adw-toggle-group.c:1045` (`adw_toggle_group_focus`) — Tab
+//     forward/backward is PROPAGATED, i.e. focus leaves the group, and every other
+//     direction goes to `adw_widget_focus_child`, i.e. moves within it.
+//     `AdwInlineViewSwitcher` builds exactly this widget with
+//     `accessible-role: GTK_ACCESSIBLE_ROLE_TAB_LIST` (adw-inline-view-switcher.c:702).
+//   - `refs/libadwaita/src/adw-sidebar.c:2168` — `gtk_list_box_set_tab_behavior (…,
+//     GTK_LIST_TAB_ITEM)`: Tab moves BETWEEN rows and their contents, i.e. the list is one
+//     stop from outside, which is the roving tabindex spelled in GTK's own vocabulary.
+//
+// That SELECTION follows focus is grounded for the sidebar and conventional for the two
+// tab lists, and the difference is worth keeping straight:
+//   - `refs/libadwaita/src/adw-sidebar.c:2167` — the sidebar's list is a `GtkListBox` in
+//     `GTK_SELECTION_SINGLE`, where moving the cursor with an unmodified arrow key selects
+//     the row it lands on. The WAI-ARIA listbox practice for a single-select listbox says
+//     the same.
+//   - `refs/libadwaita/src/adw-view-switcher.c:467` and `adw-view-switcher-button.c:337`
+//     declare `TAB_LIST` / `TAB`, but nothing in `AdwToggleGroup` changes `active` on
+//     focus: `set_active_toggle` is reached only from `toggle_active_cb`
+//     (adw-toggle-group.c:818), which fires on a real toggle. So GTK arrows those two
+//     WITHOUT switching the page — manual activation. Selection-follows-focus here is the
+//     WAI-ARIA tabs AUTOMATIC-activation pattern, chosen for consistency with
+//     `<adw-tab-view>`, which already behaves that way. Not a claim about the C.
+//
+// SELECTION IS NOT ACTIVATION. `<adw-sidebar>` emits `activated` — the documented way to
+// reveal a split view's content pane — and an arrow key must not fire it, or every press
+// navigates. `GtkListBox` splits the same two: an arrow key emits `row-selected`, and only
+// Enter/Space/click emit `row-activated`. So the callback below is a SELECT, and Enter and
+// Space stay the browser's own activation of the `<button>` the item already is.
+//
+// No wrap at the ends, following `<adw-tab-view>`, whose arrows use the non-wrapping
+// `selectPreviousPage`/`selectNextPage` (the wrapping pair is Ctrl+Tab's), and GTK, whose
+// `adw_widget_focus_child` stops at the last child.
+
+/** Which axis the items are laid out along — it decides which arrow keys move. */
+export type AdwRovingOrientation = 'horizontal' | 'vertical';
+
+export interface AdwRovingFocusInit {
+    /**
+     * The element the listener sits on — the custom element itself, so items rebuilt at
+     * any time are still covered.
+     */
+    host: HTMLElement;
+    orientation: AdwRovingOrientation;
+    /**
+     * The items a key may land on, in visual order. The widget filters: a `hidden` or
+     * `disabled` item is not navigable, and leaving one in would strand the user on a
+     * `focus()` the browser refuses.
+     */
+    items: () => readonly HTMLElement[];
+    /**
+     * Select `item`. Whether the selection actually MOVED is the widget's own business:
+     * focus travels with the key either way ({@link attachRovingFocus}).
+     */
+    select: (item: HTMLElement) => void;
+}
+
+/** The arrow pair that moves along each axis. */
+const AXIS_KEYS: Record<AdwRovingOrientation, { previous: string; next: string }> = {
+    horizontal: { previous: 'ArrowLeft', next: 'ArrowRight' },
+    vertical: { previous: 'ArrowUp', next: 'ArrowDown' },
+};
+
+/**
+ * Make a roving tabindex navigable: arrows step, Home/End jump, and focus travels with
+ * the selection so the next keypress has somewhere to start from.
+ */
+export function attachRovingFocus(init: AdwRovingFocusInit): void {
+    const { previous, next } = AXIS_KEYS[init.orientation];
+
+    init.host.addEventListener('keydown', (event) => {
+        // A modifier makes it someone else's shortcut: Ctrl+Home is "top of the document",
+        // and `Adw.TabView`'s table is full of Ctrl/Alt combinations.
+        if (event.altKey || event.ctrlKey || event.metaKey) return;
+
+        const items = init.items();
+        // `contains`, not identity: an item is a button holding an icon, a label and a
+        // badge, and a key pressed while one of those is the event target still belongs
+        // to the item.
+        const from = items.findIndex((item) => item === event.target || item.contains(event.target as Node));
+        if (from < 0) return;
+
+        let to: number;
+        switch (event.key) {
+            case previous:
+                to = from - 1;
+                break;
+            case next:
+                to = from + 1;
+                break;
+            case 'Home':
+                to = 0;
+                break;
+            case 'End':
+                to = items.length - 1;
+                break;
+            default:
+                return;
+        }
+
+        // Claimed even when nothing moves: an ArrowDown at the last row that fell through
+        // to the browser would scroll the page out from under a user who is inside the
+        // widget.
+        event.preventDefault();
+        const target = items[to];
+        if (target === undefined || target === items[from]) return;
+
+        // Selection is attempted, and focus moves REGARDLESS of whether it took. Gating
+        // the focus move on the selection having changed put the user back in the state
+        // this module exists to remove: with focus on row 0 and the selection already on
+        // row 1 — reachable by setting `selected` while focus sits elsewhere — the
+        // sidebar's `select` returned false for the row the arrow key targeted, so the
+        // press was swallowed and focus stayed on a row the roving tabindex had taken out
+        // of the Tab order. Measured in Firefox: tabIndex `[-1, 0, -1]`, two ArrowDowns,
+        // `document.activeElement` unmoved both times.
+        init.select(target);
+
+        // Focus travels with the roving tabindex or the next keypress goes nowhere — the
+        // rule `<adw-tab-view>` states. Plain `focus()`, deliberately, and NOT because
+        // these widgets have no scroller of their own: `adw-sidebar` is `overflow-y: auto`
+        // (scss/_sidebar.scss) and does. `focus()` walks every scrollable ancestor up to
+        // the window, and here that is what a GtkListBox cursor move does too — the
+        // enclosing scrolled window scrolls, and an outer one follows. Measured in Firefox
+        // on a 4000 px page: 25 ArrowDowns moved the sidebar's own `scrollTop` 0 → 898 and
+        // left `window.scrollY` at 0. `<adw-tab-view>` needs `preventScroll` for the
+        // opposite reason — C only ever writes the strip's own adjustment
+        // (`scroll_to_tab_full`), so a window scroll there is a divergence, and one
+        // ArrowRight was measured taking the window from y=1800 to y=8367.
+        init.items()[to]?.focus();
+    });
+}

package/src/elements/row-activation.ts

@@ -0,0 +1,92 @@
+// Tab stop and Enter/Space activation for the rows that libadwaita makes activatable.
+//
+// THE INCIDENT
+//
+// Measured in Firefox on an `<adw-preferences-group>` holding an activatable
+// `<adw-action-row>`, an `<adw-button-row>` and an `<adw-expander-row>`: Tab reached NONE
+// of them. Every one reported `tabIndex` `-1` and `role` `null` while all three activated
+// on click, so the whole group was operable by mouse and invisible to a keyboard. The only
+// things Tab did reach inside a group were the NATIVE controls a row happens to contain —
+// `<adw-switch-row>`'s bare checkbox and `<adw-combo-row>`'s `<select>` — i.e. the row was
+// never the thing that took focus, even where upstream says it is.
+//
+// GTK gives this free and the web renderer does not inherit it: every one of these extends
+// `GtkListBoxRow`, which is focusable by construction and activates on Enter and Space.
+//
+// WHICH ROWS, AND WHY EACH
+//
+// Derived from the C, not chosen — a row that is a tab stop it should not be turns every
+// static label into a stop, and one that is not becomes unreachable:
+//
+//   - `<adw-action-row>` only while `activatable`. A plain row is a label.
+//   - `<adw-button-row>` always: `adw-button-row.c:31` says "AdwButtonRow is always
+//     activatable", and the upstream template hardcodes it.
+//   - `<adw-expander-row>` always, on its HEADER — `adw_expander_row_grab_focus`
+//     (adw-expander-row.c:123) forwards focus to `priv->action_row`, so the header row is
+//     the focus target and the disclosure control at once.
+//   - `<adw-switch-row>` on the ROW, and its slider stops being a tab stop:
+//     `adw_switch_row_init` sets `gtk_widget_set_can_focus (self->slider, FALSE)`
+//     (adw-switch-row.c:159) and `gtk_list_box_row_set_activatable (…, TRUE)` (:160).
+//
+// `<adw-combo-row>` is deliberately NOT here. Its control is a native `<select>` stretched
+// over the row: already a tab stop, already a combobox to the accessibility tree, already
+// arrow-navigable, and already `disabled` at one option or fewer — which is exactly
+// `gtk_list_box_row_set_activatable (…, n_items > 1)` (adw-combo-row.c:194) without a line
+// of our own. Making the row the tab stop would take focus off it and put a SECOND
+// combobox in the tree.
+//
+// The key set is `GtkListBoxRow`'s: Enter and Space. Space is prevented because the
+// browser would otherwise scroll the page under the row the user just activated.
+
+/** What a row needs to become the keyboard's idea of one activatable thing. */
+export interface AdwRowActivationInit {
+    /** The element that becomes the tab stop and receives the keys. */
+    row: HTMLElement;
+    /** Re-read on every {@link AdwRowActivation.sync}: is the row activatable right now? */
+    activatable: () => boolean;
+    /**
+     * What Enter and Space do. Defaults to `row.click()` so a row keeps ONE activation
+     * path — the click handler it already has — rather than growing a second one that can
+     * drift from it.
+     */
+    activate?: () => void;
+}
+
+export interface AdwRowActivation {
+    /** Re-derive the tab stop after anything that can change `activatable()`. */
+    sync(): void;
+}
+
+/**
+ * Make `row` a tab stop while it is activatable, and activate it on Enter and Space.
+ *
+ * The listener is the element's OWN and is bound once, without teardown: it survives a
+ * re-parent and is collected with the element, so there is nothing here for
+ * `check-adwaita-connect-rebind.mjs` to hold. Only bindings that reach outside the element
+ * need releasing and re-arming.
+ */
+export function attachRowActivation(init: AdwRowActivationInit): AdwRowActivation {
+    const { row, activatable } = init;
+    const activate = init.activate ?? (() => row.click());
+
+    row.addEventListener('keydown', (event: KeyboardEvent) => {
+        // A child control owns its own keys: a `<select>`, an entry's `<input>` and a
+        // suffix button all use Enter or Space for something else, and swallowing them
+        // here would break the control to activate the row it sits in.
+        if (event.target !== row) return;
+        if (!activatable()) return;
+        if (event.key !== 'Enter' && event.key !== ' ') return;
+        event.preventDefault();
+        activate();
+    });
+
+    const sync = () => {
+        // `removeAttribute`, not `tabIndex = -1`: a row that is not activatable is not
+        // focusable at all upstream, and writing `-1` would make every static label
+        // programmatically focusable instead.
+        if (activatable()) row.tabIndex = 0;
+        else row.removeAttribute('tabindex');
+    };
+    sync();
+    return { sync };
+}

package/src/empty-sections.spec.ts

@@ -0,0 +1,81 @@
+// The `hidden` derivation itself, driven in both directions.
+//
+// `connect-lifecycle.spec.ts` drives the WIDGETS: it appends into every container a
+// consumer can reach and requires the child to be laid out. That half alone does not
+// hold the invariant — replacing the whole derivation with `section.hidden = false`
+// left the full adwaita-web browser suite green, because nothing anywhere asserted that
+// an EMPTY section is hidden or that it goes back to hidden when its last child leaves.
+// An empty bar that re-enters the flow is what that mutant ships.
+//
+// Driven against the helper rather than a widget on purpose: the two elements whose
+// sections are private fields (`<adw-alert-dialog>`, `<adw-status-page>`) have no
+// container getter, so the widget driver cannot see them, and giving them one to satisfy
+// a test would be public API invented for the test.
+import { describe, expect, it } from '@gjsify/unit';
+
+import { bindEmptySections } from './empty-sections.js';
+
+/** A section mounted in the document, since `hidden` is only observable where there is layout. */
+function section(): HTMLElement {
+    const el = document.createElement('div');
+    document.body.appendChild(el);
+    return el;
+}
+
+/** One microtask checkpoint — where a MutationObserver callback lands. */
+const settle = () => Promise.resolve();
+
+export const AdwEmptySectionsTest = async () => {
+    await describe('bindEmptySections', async () => {
+        await it('hides a section that starts empty', async () => {
+            const el = section();
+            bindEmptySections(el);
+            const hidden = el.hidden;
+            el.remove();
+            expect(`empty: hidden=${hidden}`).toBe('empty: hidden=true');
+        });
+
+        await it('shows it when a child lands and hides it again when the last one leaves', async () => {
+            const el = section();
+            bindEmptySections(el);
+
+            const child = document.createElement('span');
+            el.appendChild(child);
+            await settle();
+            const filled = el.hidden;
+
+            child.remove();
+            await settle();
+            const emptied = el.hidden;
+
+            el.remove();
+            expect(`filled: hidden=${filled} | emptied: hidden=${emptied}`).toBe(
+                'filled: hidden=false | emptied: hidden=true',
+            );
+        });
+
+        await it('counts element children, not child nodes', async () => {
+            const el = section();
+            bindEmptySections(el);
+            // The whitespace an indented `<div>\n  </div>` carries is a text node, and a
+            // section full of indentation is still an empty section. This is also why the
+            // CSS `:empty` that this looks like cannot express the rule.
+            el.appendChild(document.createTextNode('\n    '));
+            await settle();
+            const hidden = el.hidden;
+            el.remove();
+            expect(`whitespace only: hidden=${hidden}`).toBe('whitespace only: hidden=true');
+        });
+
+        await it('derives each section it is handed independently', async () => {
+            const empty = section();
+            const filled = section();
+            filled.appendChild(document.createElement('span'));
+            bindEmptySections(empty, filled);
+            const report = `empty=${empty.hidden} filled=${filled.hidden}`;
+            empty.remove();
+            filled.remove();
+            expect(report).toBe('empty=true filled=false');
+        });
+    });
+};

package/src/empty-sections.ts

@@ -0,0 +1,54 @@
+// "Hidden while it has no children" — the ONE derivation, kept live.
+//
+// THE INCIDENT
+//
+// Eight sections across five elements derived `hidden = childElementCount === 0`
+// exactly once — inside the `_initialized` guard, or inside a `_render()` only
+// `attributeChangedCallback` can reach. Neither hears a childList change. Six of them
+// document themselves as imperative append points (`<adw-toolbar-view>.topBar`/
+// `.bottomBar`, `<adw-action-row>` and `<adw-expander-row>`'s `prefixSection`/
+// `.suffixSection`), and the other two are the child slots of `<adw-alert-dialog>` and
+// `<adw-status-page>`. So a header bar appended AFTER connect sat in the DOM with the
+// right classes at offsetHeight 0, while the identical DECLARED bar rendered at 48px:
+// the compiled sheet ends with a global `[hidden] { display: none !important }`, which
+// the widget's own `display: flex` cannot beat. Measured the same in Firefox and
+// Chromium.
+//
+// `<adw-clamp>` had already paid for the same "evaluated once at connect time" shape
+// and fixed it with a MutationObserver on `{ childList: true }`. This is that TECHNIQUE
+// applied to the `hidden` derivation, with one home instead of an eighth site deriving
+// it an eighth time — the clamp keeps its own observer, because what it re-derives is a
+// width, not `hidden`. `<adw-preferences-group>` is the third live one: `hasHeaderSuffix`
+// feeds a core derivation rather than a `hidden` flag, so its existing host observer
+// watches the suffix instead.
+//
+// NOTHING TO TEAR DOWN, deliberately. The observed nodes are children this element
+// BUILT and owns, so the observer is unreachable the moment the element is, and is
+// collected with it — the same reasoning `<adw-overlay-split-view>` writes above the
+// `keydown` listener it binds once and never removes. Only a binding that reaches
+// OUTSIDE (document, window, a media query) has to be released on disconnect and
+// re-established on every connect. Keeping it bound while detached is also the better
+// behaviour: a bar appended to a parked widget is already right when it comes back.
+
+/**
+ * Hide each of `sections` exactly while it holds no element children — now, and one
+ * MICROTASK after every later childList change.
+ *
+ * The deferral is what a MutationObserver is; it matters because the derivation used to
+ * run synchronously inside `_render()`. It lands before paint, so layout is never wrong,
+ * but a caller that appends and measures in the SAME task still reads the old answer —
+ * `<adw-toolbar-view>._syncClasses` does exactly that via `offsetHeight`, and its
+ * undershoot classes are corrected by the ResizeObserver on the next frame.
+ *
+ * Element children, not child NODES: whitespace between two slotted bars is a text node
+ * and an empty bar full of indentation is still an empty bar — which is also why the
+ * CSS `:empty` this looks like cannot express it.
+ */
+export function bindEmptySections(...sections: readonly HTMLElement[]): void {
+    const derive = () => {
+        for (const section of sections) section.hidden = section.childElementCount === 0;
+    };
+    const observer = new MutationObserver(derive);
+    for (const section of sections) observer.observe(section, { childList: true });
+    derive();
+}