Skip to main content
reticle_act clicks, fills, types, selects, drags. It does exactly one thing and makes exactly one promise: the event was dispatched.
reticle_act proves nothing. If the action is supposed to cause something, use reticle_act_and_wait and get the verdict in the same call. A drive that ends on reticle_act has no result.

Example

Real response:

Actions

click · dblclick · hover · focus · blur · fill · type · clear · select · check · uncheck · submit · press · upload · scrollIntoView · drag · webmcp

Reading the effect block

This is where act earns its place even though it proves nothing.
  • valueChanged: true. The field actually took the value. false on a fill usually means the input is controlled and rejected it, or it’s readonly.
  • focusMoved: "null->e102", focus went where you expected.
  • domMutatedWithin: 15, something re-rendered within 15ms. A fill that mutates nothing often means no handler is attached.
  • defaultPrevented. A handler called preventDefault(), which is why your form didn’t submit.
  • occluded / occludedBy. The click landed on something else. This is the answer to at least half of all “the button doesn’t work” reports.

settled: false is not a failure

settleReason: "timeout" means the page was still busy when Reticle stopped watching. On a fill that’s normal and uninteresting. On a click you expected to complete something, it’s a hint that you wanted act_and_wait with an explicit until.

inputMode tells you how real the input was

synthetic means Reticle dispatched events programmatically. real means native CDP input, available under reticle drive. Synthetic input is fine for the overwhelming majority of apps; a few drag-and-drop and pointer-gesture libraries only respond to the real thing.
When the tab is backgrounded, synthetic timers and pointer gestures can silently no-op. Every response carries a warning when the tab is throttled. Pass refuseWhenThrottled: true to make Reticle throw instead of pretending it acted.
Last modified on August 14, 2026