What happened
On a run against a SolidJS app (managed headless Chrome for Testing 149, v1.8.0), the driver twice clicked a native ``'s option text inside a modal dialog and reported an app bug: "clicking a routing policy dropdown option closes the entire dialog instead of selecting it; keyboard Enter works."
The app is innocent. Reproduced manually with Playwright + CDP `Input.dispatchMouseEvent` at the exact option coordinates (same viewport, same dialog, screenshot-verified popup open): the dialog stays open and the option selects correctly. Keyboard also works. The driver's own screenshots show the dialog closed immediately after its "option" click — i.e. its click landed somewhere that dismisses the modal (the scrim element behind the panel, which the app wires to "dismiss on outside tap").
Root-cause hypothesis
Chrome renders an open `` popup in a separate widget/document. The driver's tree sees the options and reports bounds for them, but those bounds appear to be in a different coordinate space than the one `act({action:"click"})` consumes (or go stale when the popup's open state flips between observe and act). The synthesized click then lands on the page behind the popup — in our case on the modal's scrim — and the driver reasonably but wrongly attributes the result to the app.
Suggested fix
Detect native `` interaction and special-case it: open via click, then drive selection with keyboard (ArrowDown/Enter — proven working) or a DOM-level `selectOption` path, instead of a coordinate click on the option node. Short of that: when a click target's bounds came from inside an open native popup, distrust them.
Why it matters
This class produces false positives against the app under test — the worst kind of finding for a bug-hunting tool, since the whole point is trusting what it reports. Our run burned ~10 steps and recorded a phantom HIGH bug.
Evidence
Driver session: 2026-07-31_12-47-34-0003 (steps 31-32: option click → dialog closed → reopened; screenshot 030 popup open, 031 dialog gone)
Manual repro script: same Chrome binary, CDP mouse click at the option's rendered coords → dialog stays open, selection applies. Popup-open screenshot matches the driver's pixel-for-pixel.
Sibling issue #53 (persona field race) — same theme: native popup / async-render edge cases in the driver layer.
What happened
On a run against a SolidJS app (managed headless Chrome for Testing 149, v1.8.0), the driver twice clicked a native ``'s option text inside a modal dialog and reported an app bug: "clicking a routing policy dropdown option closes the entire dialog instead of selecting it; keyboard Enter works." The app is innocent. Reproduced manually with Playwright + CDP `Input.dispatchMouseEvent` at the exact option coordinates (same viewport, same dialog, screenshot-verified popup open): the dialog stays open and the option selects correctly. Keyboard also works. The driver's own screenshots show the dialog closed immediately after its "option" click — i.e. its click landed somewhere that dismisses the modal (the scrim element behind the panel, which the app wires to "dismiss on outside tap"). Root-cause hypothesis Chrome renders an open `` popup in a separate widget/document. The driver's tree sees the options and reports bounds for them, but those bounds appear to be in a different coordinate space than the one `act({action:"click"})` consumes (or go stale when the popup's open state flips between observe and act). The synthesized click then lands on the page behind the popup — in our case on the modal's scrim — and the driver reasonably but wrongly attributes the result to the app.
Suggested fix
Detect native `` interaction and special-case it: open via click, then drive selection with keyboard (ArrowDown/Enter — proven working) or a DOM-level `selectOption` path, instead of a coordinate click on the option node. Short of that: when a click target's bounds came from inside an open native popup, distrust them. Why it matters This class produces false positives against the app under test — the worst kind of finding for a bug-hunting tool, since the whole point is trusting what it reports. Our run burned ~10 steps and recorded a phantom HIGH bug. Evidence Driver session: 2026-07-31_12-47-34-0003 (steps 31-32: option click → dialog closed → reopened; screenshot 030 popup open, 031 dialog gone) Manual repro script: same Chrome binary, CDP mouse click at the option's rendered coords → dialog stays open, selection applies. Popup-open screenshot matches the driver's pixel-for-pixel. Sibling issue #53 (persona field race) — same theme: native popup / async-render edge cases in the driver layer.