Skip to main content
reticle_wait_for takes the same predicate grammar as reticle_act_and_wait, without the action. Use it when the thing you are waiting for was triggered by something other than your own click. A timer, a websocket push, a background refresh.

Example

Real response:
The evidence is the element itself, with the file and line that rendered it.
Look at visible: false and states: ["present", "hidden", "enabled"]. The alert exists in the DOM and is not visible. wait_for on a text predicate matches presence, if you need it on screen, that is a different question, and reticle_inspect answers it.

It checks the buffer first

wait_for does not always wait. If the predicate is already satisfied in the recent event buffer, it returns immediately. This means you can act, then wait, without racing. The event that happened while you were composing the second call is not lost.

Arguments

Prefer act_and_wait when you caused it

If your own action is supposed to trigger the thing, put the predicate in the action:
One call instead of two, no gap for an event to slip through, and. The part that matters. The expectation is recorded before the action rather than chosen after it. Save wait_for for consequences you did not cause.
Last modified on August 14, 2026