pup_alert_window fails after a tab switch changes the window title (resolve by hwnd, not title)

by adom

pup gives your AI a real browser on your desktop that it drives completely, in the background, signed in as you: windows that never jump in front of your work, one shared profile that learns your logins, and every window labeled on the taskbar with its AI thread's name.

Overview Files Skills Discover Packages Releases Dependencies Issues17 Breadcrumbs Pull Requests1 Activity

Closed general

John Lauer · 2mo ago ·closed by John Lauer

pup_alert_window loses its own window after pup_switch_tab changes the OS title. Repro tonight on AdomLapper (kicad-bridge dev thread): pup_open_window {sessionId:"ai-kicad-bridge-dev", url:} then pup_open_tab then pup_switch_tab back to tab-1, then pup_alert_window {window:"ai-kicad-bridge-dev"} returns "AD desktop_flash_window did not match the window (title changed? window closed?)". The window was alive the whole time; flashing it directly by hwnd via AD desktop_flash_window {hwnd} succeeded immediately. Looks like the alert path resolves the OS window by title snapshot instead of the cached hwnd, so any tab switch (which rewrites the Chrome window title) breaks it. Suggested fix: resolve by the tracked hwnd first and fall back to title only when the hwnd is dead. First flash right after window creation worked; only post-tab-switch flashes fail.

1 Reply

John Lauer · 2mo ago

Fixed in 2.0.242-2.0.243, and your exact repro now passes end to end (open window, open a second tab, switch back to tab-1, alert → applied: true).

The title theory was a red herring, and the error message caused it. pup already targets that window by HANDLE, and it had the right one the whole time (pup_window_info reported hwnd 3081334 while the alert was failing, and the overlay badge was painting on that same handle every cycle). The real cause: this desktop runs minimalTouch: "on", and flashViaAD returns early under that gate unless the caller passes force. pup_alert_window did not, so the flash was silently swallowed — and the response then reported the generic failure hint, "AD desktop_flash_window did not match the window (title changed? window closed?)". That sentence sent both of us at the resolver. Flashing directly through ab worked precisely because ab is not subject to pup's gate, which looked like evidence for the title theory.

Two changes:

2.0.243 — pup_alert_window now passes {force:true}. Minimal-touch exists to suppress pup's AUTOMATIC machinery (its own comment says so); a caller explicitly asking for a nudge is the opposite of automatic, and the helper already had the lever.
2.0.243 — the failure hints stop lying. A flash skipped by the gate now says so and names the setting to change (pup_configure {minimalTouch:"off"}); a genuine failure says pup targets by handle, that title tags are off by default, and points at pup_window_info for the handle in use.

Also shipped alongside (2.0.242), because your suggestion was right as a general hardening even though it was not this bug: the handle pup captures when it CREATES a window (page.__pupHwnd) is now consulted by the flash, park and window-target resolvers before any title lookup. It survives title changes, tab switches and parking, and needs no enumeration.

Note for anyone hitting this class: titleTag has defaulted to off since 2.0.20, so any code path that falls back to a (session: X) title lookup cannot match on a default install. Two related cases in ab are filed as adom/adom-bridge#84 (pup_lower_os_window) and #83 (port assignment).

John Lauer closed this · 2mo ago