[Bug]: click() cannot open Radix-style popovers — the delivered input has no pointer events

Affected component

ego-browser runtime or CLI

What happened?

On the current GitHub issues UI, the reaction picker on an issue comment (a Radix UI popover) could not be opened by any ego interaction:

• click('@ref') on the trigger button
• click([x, y]) at the trigger's exact center
• hover([x, y]) + wait
• DOM el.click() via js()
• focus() on the trigger + pressKey('Enter')

After every attempt the popover was absent from the DOM (probed [role="menu"], [data-radix-popper-content-wrapper] and the picker's emoji buttons — nothing appears), while click() resolved successfully.

Key observation: capture-phase listeners on document recorded the input delivered by a click() call as exactly mousedown → mouseup → click — no pointerdown / pointerup / pointermove. Radix (and a large share of modern React UI) drives its popovers/menus from pointer events, so a mouse-only sequence never activates the trigger.

Per the internals documented in #229, the probe fallback in pointer.ts synthesizes mousedown/mouseup/click only. When that fallback engages, every "successful" click is mouse-only, which silently breaks pointer-event-driven UI while still reporting success.

Steps to reproduce

1. Open any GitHub issue page while logged in.
2. In one heredoc: install capture-phase listeners for pointerdown/pointerup/mousedown/mouseup/click on document, then call click() on the emoji "React" button of the main post — by ref, by coordinates, via hover(), or via focus() + pressKey('Enter').
3. Observe: the listener log records mousedown/mouseup/click only (no pointerdown/pointerup), and the reaction picker never appears in the DOM.

Expected behavior

click() should deliver an input sequence that includes pointer events (e.g. via Input.dispatchMouseEvent, which synthesizes them), so Radix / floating-ui style popovers open. If only a mouse-event-only fallback was possible, that condition should be surfaced instead of the call reporting success.

Version

ego-browser skill 1.2.3; ego lite 0.4.7.4

Environment

macOS 26.6.2 (Apple Silicon); agent-driven ego-browser heredocs

Logs or screenshots

Capture-phase event log recorded while calling click() on a page button (events reached the element, handler fired):


["mousedown target=btnList x=540 y=791","mouseup target=btnList x=540 y=791","click target=btnList x=540 y=791"]


No pointer events are present in the log.

DOM probe after each interaction attempt on the Radix trigger:


{"emojiLeaves":[],"wrappers":[]}


(no [data-radix-popper-content-wrapper], no [role="menu"], no picker buttons appear)

Additional context

• Sibling of #229 — same probe-and-fallback path introduced in #65. #229 covers the fallback synthesizing a primary-button click for right/middle buttons; this report covers the delivered sequence lacking pointer events entirely.
• #293 suggests real input can be unreliable while the ego lite window is occluded/backgrounded, which may be exactly when the mouse-only fallback engages.
• Workaround: none found for opening such popovers. Plain click-handler buttons still work via DOM el.click() through js().

Before submitting

• I searched the existing issues and did not find a duplicate.
• I removed secrets and sensitive browsing data from this report.