Reliability & waits

Mobile screens animate, load late, and render controls off-screen. Trq has several layers that keep replays stable — most on by default.

Auto-scroll into view

When a tap / type / checkbox / radio targets an element that isn't on screen, Trq scrolls to find it first — the mobile equivalent of scrolling before a click. It's element-targeted, so it survives a layout whose height changed since you recorded. For a below-the-fold assertion (which deliberately doesn't hunt), right-click the step → Insert scroll-to before to add an explicit scroll with the same target (see insert steps).

Readiness & waits

Before a coordinate tap, a readiness gate waits for the screen to settle so the tap doesn't fire on a half-drawn frame. Per-action timeouts (find, assert, settle, launch) are tunable per session or per step — see settings.

Verify-after-type

Custom inputs sometimes swallow keystrokes. With verify-after-type on, Trq re-checks that the text actually landed and fails the type step if it didn't — instead of a confusing failure at a later assert. A stricter exact-match mode clears and retypes when a field ends up with the wrong contents.

Auto-retry & flaky reporting

Some steps fail intermittently — a submit that only sometimes advances, an OCR field that's slow to populate. Give a step an Attempts count (with optional rewind + backoff) in the Edit drawer: if it fails, Trq rewinds a few steps, waits, and replays forward — up to the budget — before pausing you.

A step that only passed after a retry is flagged flaky: it shows an amber ↻ badge instead of a green ✓, and the Summary counts it under a Flaky stat — so you can see which steps are unstable even on a green run.

This is the same retry engine used by web, so behaviour is identical across platforms.