← Commit history

Dev skill: flash-state focus hook must inject into the current document too, not only future navigations

John Lauer ·494d59b351 · ·parent 5dc9f3f
1 file changed +8−4
dev-skills/pup-bridge-dev/SKILL.md+8−4
@@ -402,10 +402,14 @@ The flash SET routes through **AD-core `desktop_flash_window`** (`flashViaAD`);   move off-screen → `SetForegroundWindow` (invisible, clears the tint) → park back on-screen z-bottom →   hand focus back (`AttachThreadInput`). This is `osClearFlashByActivate`, wired into `browser_alert_window   {stop}`. It reports `cleared` / `already-foreground` (not a fire-and-forget guess).-- **Programmatic flash STATE** (answer "which windows are still flashing?" without a screenshot):-  `getSessionInfo.flash` = `none|pending|cleared`, from the server-side flash ts (`_flashState`) vs the-  in-page focus latch `window.__pupFocusTs` (injected `focus` listener). `pending` = flashed, user has not-  activated it since; `cleared` = user activated it after the flash.+- **Programmatic flash STATE** (answer "which windows are still flashing?" / "which window hasn't the+  user seen?" without a screenshot): `getSessionInfo.flash` = `none|pending|cleared`, from the+  server-side flash ts (`_flashState`) vs the in-page focus latch `window.__pupFocusTs` (injected+  `focus` listener). `pending` = flashed, user has not activated it since; `cleared` = user activated+  it after the flash. **Gotcha (cost a live demo):** the hook must be injected into the CURRENT+  document with `page.evaluate` IN ADDITION to `evaluateOnNewDocument` — the latter only fires on the+  NEXT navigation, so an already-navigated page never gets the hook and every clicked window keeps+  reporting `pending` (v1.8.45-55 bug, fixed 1.8.56).  **Meta-rule (John, 2026-07-14):** think through ALL the variables before shipping a window/focus change — human-usability AND AI-automation together. When John gives new feedback here, **write it into THIS skill**