Auto-waiting

Before it drives an element, taqwright runs a short set of actionability checks and retries them until they pass, polling every 200 ms up to the timeout (30 seconds by default, see Timeouts). Once the checks pass it performs the action; if they never pass, the action fails with a timeout-style error. This is why you rarely need an explicit wait: tapping a button that is still animating in, or filling a field that has not rendered yet, just works.

tests/login.spec.ts

import { test, expect } from '@taqwright/taqwright';

test('sign in', async ({ mobile }) => {
  // No manual wait: click auto-waits for the button to be visible and enabled.
  await mobile.getByLabel('Login').click();
  await expect(mobile.getByLabel('View All')).toBeVisible();
});

The checks

Taqwright performs two actionability checks:

• Visible — the element is present in the UI tree and displayed on screen.
• Enabled — the element is interactive (not disabled).

Which action waits for what

Actions that change the UI wait for the element to be visible and enabled. Read-only queries and screenshot only wait for it to be visible.

Waits for	Methods
Visible + Enabled	click / tap, doubleTap, longPress, fill, clear, check / uncheck, focus, press, pressSequentially, selectOption, swipeLeft / swipeRight / swipeUp / swipeDown, pinchIn / pinchOut, dragTo / dragToPoint, isEnabled
Visible only	screenshot, getText, getValue, getAttribute, boundingBox, isFocused, isEditable, isInViewport, isEmpty

Every action accepts a { timeout } to override how long it waits (see Timeouts).

Waiting explicitly

When you need to wait for a state the implicit checks do not cover, call waitFor on the locator. It accepts 'visible', 'hidden', 'attached', 'enabled', or 'disabled':

// Wait for a loading spinner to disappear before reading the screen.
await mobile.getById('spinner').waitFor({ state: 'hidden' });

// Wait for an element to exist in the tree, even if not yet displayed.
await mobile.getById('result').waitFor({ state: 'attached' });

Assertions wait too

The auto-retrying assertions use the same polling loop as the action waits: assertVisible(), toHaveText(), toHaveCount(), and the rest all retry until the condition holds or the timeout elapses. See Assertions.

What taqwright does not wait for

Taqwright's auto-wait is narrower than Playwright's web actionability. It does not:

• wait for an element to be stable (it does not watch for animations to settle), so an action can land mid-transition;
• hit-test that the element actually receives the touch, so an element covered by an overlay can still be driven;
• pre-check editable before fill (it waits for visible and enabled, then falls back to an editable descendant if typing is rejected).

There is also no force option, because there are no non-essential checks to skip. In practice: after triggering a transition, assert the destination element is visible (the assertion retries) before acting on it; use scrollIntoView to bring an element on-screen; and dismiss overlays or dialogs explicitly rather than relying on hit-testing.

See Actions for the actions these waits apply to and Writing tests for the basics.