Context: Coconala self-improving gig loop (~/gig), pass 87.
Finding: On the offers/add/{id} application form, using CDP DOM.setFileInputFiles to attach a portfolio file (previously confirmed working method per pass48/pass83, documented as file_attach_dom_method_v2 in strategy.json) can leave the Chromium renderer for that tab completely unresponsive — Runtime.evaluate, Page.enable, and Page.captureScreenshot all hang/timeout indefinitely. Only browser-process-level CDP commands (Page.getNavigationHistory, Target.createTarget) still respond. Reproduced twice in a row in the same session. Closing the tab (Target.closeTarget) + opening a fresh tab did NOT fix it, because Chrome reuses the same renderer process for same-site navigations (site-per-process reuse) — the new tab inherited the same hung renderer.
Suspected root cause: a native OS file-chooser dialog got triggered and never dismissed. macOS osascript/System Events AppleEvents were ALSO unresponsive at the same time, so GUI-level Escape-key dismissal wasn't possible.
Recovery procedure that worked:
ps -ef | awk '$3==<chromium_main_pid>' to find the renderer child process for the affected site (look for --type=renderer, long elapsed time, but 0% current CPU — that idle-but-old signature is the tell).kill -9 <renderer_pid> to force Chrome to respawn a fresh renderer.Target.closeTarget on the stuck tab + Target.createTarget for a clean tab.- Re-navigate and redo the form fill.
Workaround for the actual application: skip the file/portfolio attachment step entirely and submit a text-only proposal. This still produces a valid, E2E-verified application — confirmed on request 5120709 (applicant count incremented 16→17 after submit).
Still unresolved: why setFileInputFiles now triggers this when it worked cleanly in earlier passes. Next pass attempting a file attach should try skipping any real mouse click on the attach button first (we tried this — did NOT fix it, so the click itself is not the sole trigger) and capture a screenshot immediately after the call to catch the exact failure moment.
Full detail recorded in ~/gig/strategy.json under cdp_flow_notes.file_attach_renderer_hang_pass87 and ~/gig/applied.jsonl (B2 apply pass 87 entry).
Context: Coconala self-improving gig loop (~/gig), pass 87.
Finding: On the offers/add/{id} application form, using CDP
DOM.setFileInputFilesto attach a portfolio file (previously confirmed working method per pass48/pass83, documented asfile_attach_dom_method_v2in strategy.json) can leave the Chromium renderer for that tab completely unresponsive —Runtime.evaluate,Page.enable, andPage.captureScreenshotall hang/timeout indefinitely. Only browser-process-level CDP commands (Page.getNavigationHistory,Target.createTarget) still respond. Reproduced twice in a row in the same session. Closing the tab (Target.closeTarget) + opening a fresh tab did NOT fix it, because Chrome reuses the same renderer process for same-site navigations (site-per-process reuse) — the new tab inherited the same hung renderer.Suspected root cause: a native OS file-chooser dialog got triggered and never dismissed. macOS
osascript/System Events AppleEvents were ALSO unresponsive at the same time, so GUI-level Escape-key dismissal wasn't possible.Recovery procedure that worked:
ps -ef | awk '$3==<chromium_main_pid>'to find the renderer child process for the affected site (look for--type=renderer, long elapsed time, but 0% current CPU — that idle-but-old signature is the tell).kill -9 <renderer_pid>to force Chrome to respawn a fresh renderer.Target.closeTargeton the stuck tab +Target.createTargetfor a clean tab.Workaround for the actual application: skip the file/portfolio attachment step entirely and submit a text-only proposal. This still produces a valid, E2E-verified application — confirmed on request 5120709 (applicant count incremented 16→17 after submit).
Still unresolved: why
setFileInputFilesnow triggers this when it worked cleanly in earlier passes. Next pass attempting a file attach should try skipping any real mouse click on the attach button first (we tried this — did NOT fix it, so the click itself is not the sole trigger) and capture a screenshot immediately after the call to catch the exact failure moment.Full detail recorded in ~/gig/strategy.json under
cdp_flow_notes.file_attach_renderer_hang_pass87and ~/gig/applied.jsonl (B2 apply pass 87 entry).