Overview
A selector tells the executor which DOM element to interact with. Selectors use multiple fields as fallback strategies — the executor tries each in priority order until a match is found.Selector fields
Resolution pipeline
The executor resolves selectors through a 6-stage pipeline:1
Deterministic resolution
Tries each selector field in priority order (id → ariaLabel → … → name). No AI needed.
2
AI selector resolution
If deterministic resolution fails, AI analyzes the current page snapshot to find the target element.
3
Smart retry (3x)
Retries with increasing timeouts, waiting for DOM changes between attempts.
4
Scroll recovery
Scrolls the page to locate off-screen elements.
5
Agent Fallback
AI agent explores alternative paths to reach the target element. Requires Pro+ plan.
6
Vision Fallback
Takes a screenshot and uses vision AI to locate the element visually. Requires Pro+ plan.
Example
- Try
#submit-btnfirst - Fall back to
[aria-label="Submit form"]if the id is not found - Fall back to matching
innerTextif aria-label fails - Use
roleandtagNameas additional filters throughout
rect (position fallback)
Used as a last-resort deterministic strategy. Coordinates are relative to the viewport.
Position-based selectors are fragile — they break when the layout changes. Prefer semantic selectors (
id, ariaLabel, dataTestId) whenever possible.dataAttributes
Match elements by custom data-* attributes:
<div data-row-id="42" data-status="active">.
Best practices
- Prefer stable identifiers —
id,dataTestId, andariaLabelsurvive UI redesigns better than CSS selectors or XPath. - Avoid
rect— Position selectors break on any layout change. Only use them when no semantic selector exists. - Keep
innerTextshort — Long text matches are brittle. The field is capped at 200 characters. - Enable selector cache — For repeated executions,
--enable-selector-cachepersists successful resolutions across runs.