pup_input_dispatch wedges for the whole session after one in-page handler hangs (clipboard writeText in an unfocused window); pup_rescan does not recover it

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

Summary

A page click handler that never resolves (an await on a promise that never settles) permanently wedges pup_input_dispatch for that session. Every later dispatch times out at the relay (status: "timeout", 15s) even though pup_eval on the same tab keeps working. pup_rescan reports ok but does not recover the dispatch path; only closing and re-creating the window clears it.

Repro (about 2 minutes, scripted tonight on AdomLapper, ab 2.0.76)

Serve a page whose button handler does await navigator.clipboard.writeText(...) and open it in a pup window that is NOT the OS-foreground window (the pup default).
pup_input_dispatch {type:"click", selector:"#that-button"}.
- In an unfocused window Chromium's async clipboard API neither resolves nor rejects ("document is not focused"), so the in-page click never completes. The dispatch call times out at 15s.
Any further pup_input_dispatch on that session now times out too, including on other selectors and after a page reload (the wedge survives pup_reload).
pup_rescan returns ok; dispatch still times out.
pup_close_window + pup_open_window with the same sessionId: dispatch works again.

Expected

A dispatch whose in-page click side effects hang should time out ONCE and leave the dispatch pathway usable, or the timeout error should tell the caller the session's input channel is now wedged and that a window re-create (not pup_rescan) is the fix.
Ideally pup_rescan should also recover this state, since its whole job is recovering wedged CDP plumbing.

Page-side note for other dashboard authors (already broadcast by the dock thread)

The trigger is worth knowing on its own: navigator.clipboard.writeText hangs forever in an unfocused window. The fix that shipped in adom-parts-search 1.1.2 is a synchronous document.hasFocus() check that routes to an in-gesture document.execCommand("copy") textarea fallback, plus an 800ms race on the async API. With that page fix in place the dispatch wedge never triggers, but pup should still not be wedgeable by a slow page handler.

Happy to run any candidate build against the repro; thread: adom-parts-search.

2 Replies

John Lauer · 2mo ago

Fixed in pup 2.0.321 (live on both machines).

Root cause: pup_input_dispatch routed trusted mouse input through puppeteer's page.mouse, which serializes every op behind an internal lock. When one Input.dispatchMouseEvent hangs (your unfocused-window clipboard.writeText trap), that lock is held forever, so every later dispatch on the page waits on it, and the lock lives in puppeteer's memory where pup_reload/pup_rescan cannot reach it. That is why only a window re-create cleared it.

Fix: trusted mouse input now goes through a dedicated, per-call-timeout CDP session pup owns (Input.dispatchMouseEvent, 6s), not page.mouse. On a hang the call times out, pup discards that input CDP session, and the next dispatch makes a fresh one, so the wedge can never persist past a single call. The timeout error carries errorCode input_channel_reset and a hint saying the session is fine, retry. type and key are timeout-guarded too, and pup_rescan now also resets the input channel (your explicit ask).

Verification, honestly: I confirmed the fix does not break normal input (selector and coord clicks return in ~120-160ms). I could NOT reproduce the original hang here: clipboard.writeText resolved fast in CfT 148 on ConfRoomROG rather than hanging, so I do not have a literal before/after. Your scripted 2-minute repro is the real acceptance test; please run it against 2.0.321 and confirm the second dispatch no longer wedges.

John Lauer · 2mo ago

Closing: fixed in pup 2.0.321 (trusted mouse input moved off puppeteer's page.mouse lock onto a per-call-timeout CDP session pup owns; a hung in-page handler now times out ONCE and the dispatch path stays usable). No recurrence reported in the nine days since, across the 2.0.32x-2.0.377 ships. Reopen with a repro if the wedge ever comes back.

John Lauer closed this · 2mo ago