webpage_click
Click an element in the device browser, by CSS selector or by a ref from a page-elements listing — works on BOTH iOS Safari and Android Chrome, auto-detected from the udid. Scrolls the element into view, waits for it to stop moving, and checks it is actually clickable — visible, non-zero-size, enabled, and not covered by anything — retrying until timeoutMs before it gives up. Then taps its center. On iOS the DEVICE taps its own screen at that position, so the page receives a real, fully trusted touch — pointerdown, touchstart, mousedown and click, exactly as from a finger — which also satisfies sites that gate on trusted input. On Android the tap is delivered as a TOUCH through the browser, so elements listening for pointer events respond as well as those listening for click. Falls back to mouse events, then a plain .click(), if a step is unsupported, and the response reports which was used via via. ERRORS rather than reporting success when the element never becomes clickable; pass force:true to skip the checks and dispatch at its coordinates anyway — which works for anything that still occupies a box, but NOT for a display:none or zero-size element, where there is no point to aim at and force fails too. When a selector matches several elements the first VISIBLE one wins, not the first in document order. This is COORDINATE-based. Android events are synthesized by the browser (isTrusted:false); iOS taps are real device input (isTrusted:true) whenever via comes back as "nativeTap".
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Element ref from a page-elements listing, e.g. "e12". Provide this or `selector`. A ref points straight at the element it was issued for, so it survives markup that shifted position, and it can address elements no CSS selector can reach from the top of the page. | |
| udid | Yes | Device UDID / serial (iOS or Android) | |
| force | No | Skip the clickability checks and dispatch at the element center regardless (default: false). Use only when the checks are wrong about a target you know is clickable — it restores the old behaviour, where a click on a hidden or covered element reports success without doing anything. Needs a center to aim at, so it still fails on a display:none or zero-size element; it does apply to visibility:hidden, opacity:0, pointer-events:none, disabled, off-viewport, and covered targets. | |
| pageId | No | Target page/tab id — auto-picked when omitted | |
| socket | No | Android only: abstract unix socket name (default: chrome_devtools_remote) | |
| selector | No | CSS selector for the target element. Provide this or `ref`. | |
| snapshot | No | Append a webpage_snapshot of the resulting page (actionable elements only) so you can see what the click changed without a second call (default: false) | |
| timeoutMs | No | How long to keep retrying while the element is not yet clickable (default: 5000, max: 30000) | |
| pointerType | No | How the tap is delivered. You rarely need this — the default is the best path each platform has (a real device tap on iOS, a browser touch on Android). "touch" is what a finger produces and drives elements that listen for pointer events, which many component libraries bind. On Android a touch also produces mousedown/mouseup unless a handler cancels pointerdown or touchstart — and when one does, click is suppressed too, which is when "mouse" is the way through. "mouse" sends mouse events only, and on iOS it opts OUT of the device tap in favour of the browser-level path, which delivers only mouseup+click and is not trusted. The response reports which was used via `via`. | |
| platformVersion | No | Ignored (kept for compatibility) |