Discovered while building the mouse demo GIFs (#543).
Symptom: clicking an untrusted URL with mouse_urls in .ask_each mode does arm the [y]/[a]/[t]/cancel trust banner (the module sets armed = true and onMouseClick returns .consume), but the banner — rendered via the module's statusText — is not painted until the next output or keystroke. A user clicking a URL therefore sees no prompt until they happen to type, at which point the keystroke is consumed as the banner's answer (e.g. Esc → "url-open cancelled").
Root cause: in src/proxy.zig, the stdin path calls D.dispatchMouseClick(...) but does not call renderStatus(...) afterwards (the other input/output paths do). A consumed click can change a module's statusText without producing any output, so the bar goes stale until an unrelated repaint.
Fix sketch: after dispatchMouseClick, repaint the bar — if (statusbar) |*sb| { if (!alt_screen.active and !cursor_tracker.inEscape()) renderStatus(&runtimes, &ctx, sb, &out_buf, incognito_on) catch {}; }. In a quick prototype the renderStatus call alone didn't reliably surface the armed banner in the scripted e2e env (it painted on the next keystroke, not the click), so this needs investigation into the click→repaint→flush timing (and a tests/demo/mouse_urls/ GIF once it lands, using the new click DSL verb from #543).
Until then the mouse_urls demo GIF is deferred; mouse_links ships in #543.
Discovered while building the mouse demo GIFs (#543).
Symptom: clicking an untrusted URL with
mouse_urlsin.ask_eachmode does arm the[y]/[a]/[t]/canceltrust banner (the module setsarmed = trueandonMouseClickreturns.consume), but the banner — rendered via the module'sstatusText— is not painted until the next output or keystroke. A user clicking a URL therefore sees no prompt until they happen to type, at which point the keystroke is consumed as the banner's answer (e.g. Esc → "url-open cancelled").Root cause: in
src/proxy.zig, the stdin path callsD.dispatchMouseClick(...)but does not callrenderStatus(...)afterwards (the other input/output paths do). A consumed click can change a module'sstatusTextwithout producing any output, so the bar goes stale until an unrelated repaint.Fix sketch: after
dispatchMouseClick, repaint the bar —if (statusbar) |*sb| { if (!alt_screen.active and !cursor_tracker.inEscape()) renderStatus(&runtimes, &ctx, sb, &out_buf, incognito_on) catch {}; }. In a quick prototype therenderStatuscall alone didn't reliably surface the armed banner in the scripted e2e env (it painted on the next keystroke, not the click), so this needs investigation into the click→repaint→flush timing (and atests/demo/mouse_urls/GIF once it lands, using the newclickDSL verb from #543).Until then the
mouse_urlsdemo GIF is deferred;mouse_linksships in #543.