confirm() from a driven click wedges the page: no auto-dismiss, handle_dialog can't resolve it, evals block until window close

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

Closed bug report

John Lauer · 2mo ago ·closed by John Lauer

A confirm() raised by an isTrusted click wedges the page: drive-mode auto-dismiss does not fire, handle_dialog cannot resolve it, and every subsequent eval blocks until the window closes.

Found by the daily verb battery. Fixture: #confirm-btn does window.confirm(...) in its onclick. Sequence: nbrowser_click #confirm-btn -> nbrowser_handle_dialog {action:"accept"} -> eval.

Observed (bridge 0.2.5, ext 0.2.0):

The events-doc contract says dialogs are "auto-dismissed while you are actively driving" - this one is NOT auto-dismissed (the click that opens it IS a driven, isTrusted click).
handle_dialog {action:accept} returns the "modal may have closed" no-pending response while the dialog is demonstrably still up.
All subsequent evals return no result (page JS blocked by the pending confirm) until nbrowser_close_window tears the window down (which succeeds - so recovery works, resolution does not).

Expected: either the auto-dismiss covers dialogs opened by driven clicks (and reports via nbrowser_events), or handle_dialog resolves a pending dialog. Today neither path works, so any user flow that trips a confirm() dies mid-drive - the Intuit incident class the driving skill warns about.

Battery quarantines this as a known-bug pending fix; the test asserts dlg-note becomes confirm:true (accept landed) or confirm:false (auto-dismiss won).

1 Reply

John Lauer closed this · 2mo ago

John Lauer · 2mo ago

Fixed in extension 0.2.8 (2026-08-22), verified by the daily battery and still green today. The fix is a page-level PRE-ANSWER instead of trying to resolve the native dialog after it opens: nbrowser_handle_dialog {policy:manual, accept, text} arms an override of window.confirm/alert/prompt under window.__nbDlg, so a driven click's confirm() returns the armed answer without a native dialog ever blocking the page; {policy:auto} disarms and returns seen[] with every dialog that was answered. Ground truth that shaped it: Chrome CANCELS JS dialogs while a debugger is attached, so no post-hoc handling can work. Battery row today: handle_dialog live ok, note pre-answer landed: confirm:true; seen:1 (84 pass, 0 fail on ConfRoomROG chrome:[email protected]). The click path also stopped retrying into a frozen page: a click whose only effect was a dialog now returns changed:true with dialogOpened:{type,message} rather than dispatching a second click that used to fire a second confirm(). Closed.