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.
Tapping an element that is still moving
The readiness gate waits for the whole screen; this waits for the one element you're aiming at.
Finding an element gives Trq its position at that instant. Sending the tap takes another 50–100 ms, and on a screen that is still settling — a list bouncing to rest, a sheet sliding up, a row growing as its image loads — the element has moved by the time the tap lands. It hits the row above or below instead. That fails perhaps one run in twenty, and never while you're watching.
So before every element tap Trq re-reads the element until its position stops changing, then taps where it is now. A screen that is already still costs one extra read; the budget is only spent when something is genuinely moving.
It can't make a step fail. The element has already been found, so a screen caught mid-transition means look again, and a spent budget means tap the best-known position — which is what Trq did before. Turn it off per session or per step if you need the milliseconds back.
Tap points are also clipped onto the display. An element scrolled half off the top reports a negative position, and the centre of that is a coordinate the device discards — so the tap simply didn't happen.
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.