# Window-level input guards

`attachEndTurn` in `ui.ts` binds its Enter/Space handler to `window`, not to
the End Turn button. That one decision has now produced three separate bugs,
each found after the guard was believed correct:

1. 2026-09-06 — `button.disabled` suppresses the button's own click but has
   no effect on a window listener, so Enter/Space kept ending turns after a
   win. Fixed by moving the real legality check into `game.ts`.
2. 2026-09-07 — adding a `<select>` meant Space (which opens the dropdown)
   also ended the turn. Fixed by widening the guard from "is the End Turn
   button focused" to "is any form control focused."
3. 2026-09-08 — the concede `<dialog>`. `showModal()` makes the background
   *content* inert (pointer events, focus, tab order) but has NO effect on a
   listener bound to `window`: a keydown inside the dialog still bubbles
   through the dialog to `document` to `window`. Clicking the dialog's
   non-focusable body text moved focus off Cancel onto the `<dialog>`
   element, defeating the form-control check, so Enter ended the turn behind
   the open modal — and because the dialog's player name is set once at open
   time, confirming afterwards would have conceded a *different* player than
   the one named. Fixed by bailing on any open dialog.

Two rules follow:

- Modal inertness is not listener protection. Nothing about `showModal()`,
  `inert`, or `pointer-events: none` stops an event from reaching a
  `window`/`document` listener. Guard explicitly.
- A guard on a window-level listener is a claim, and it needs a dispatched
  event behind it, never code inspection. Assert on the event's own
  `defaultPrevented` (see the technique bullet in
  `build-and-serve.md`) plus the state that must not have changed. All
  three bugs above passed a reading of the code; two of them were caught
  only by dispatching, and the third by predicting the dispatch would fail.