Skip to main content
Real response:

confirmed: false is the honest part

A full navigation destroys the document the SDK was living in. Reticle cannot report on the new page from inside the old one, because the old one no longer exists. So it tells you what it actually knows: the navigation was dispatched. Most tools would return ok: true and let you assume arrival. When the page then fails to load, or loads without instrumentation, you get a confusing cascade of “element not found” errors several calls later, with nothing pointing at the real cause.

The pattern after navigating

then confirm a session reconnected:
with reticle_sessions, and only then snapshot. If no session appears at the new URL, the page did not load or is not instrumented. And you know that immediately rather than three calls later.
Refs do not survive a navigation. A new document means new refs. The same “Sign in” button was e5 before a navigation and e103 after. Re-snapshot; never carry refs across.

Arguments

Client-side routing is different

In a single-page app, clicking a link usually changes the route without destroying the document. That is a route change, not a navigation. Refs survive, and you can assert it directly:
Use reticle_navigate for a genuine document load. A deep link, a hard reload, or the first visit.
Last modified on August 14, 2026