context.setOffline(true) flips navigator.onLine in one line. The hard part is what comes next.

Because networkidle is defined by Playwright as 500ms with no more than 2 in-flight network requests. After you flip the context to offline, the page is allowed to fire as many failing requests as it wants, and any retry loop on the page will keep that count above 0 indefinitely. networkidle was designed to wait for a network to settle, not for a network that is dead. The official docs even discourage it for new code. After setOffline(true), it is the wrong tool category.

You can, but it gets you a flaky test. The page might dispatch the offline event in 12ms on a hot CI runner and 380ms on a cold local container. A fixed 500ms wait either underwaits and asserts on a half-rendered banner or overwaits and burns a second on every test run. Multiplied across a CI suite that runs hundreds of offline assertions, that is real money. Assrt avoids fixed waits entirely. The wait_for_stable tool measures actual DOM activity instead.

An MCP tool exposed by the Assrt agent that injects a MutationObserver into the page, counts childList + subtree + characterData mutations, and returns once the count has not changed for a configurable quiet period. Source: /Users/matthewdi/assrt-mcp/src/core/agent.ts:941-994. The default is 2 seconds of quiet within a 30 second timeout. Both are capped: stable_seconds maxes at 10, timeout_seconds maxes at 60. The poll interval is hardcoded at 500ms.

requestIdleCallback measures main thread idle, which is unrelated to whether your offline UI has finished rendering. The 'load' event has already fired by the time you call setOffline. The only signal that genuinely tracks 'the offline UI has stopped changing' is the DOM diff itself. MutationObserver is the browser's native way to watch the DOM diff. Polling a counter every 500ms beats subscribing to the observer callback because it lets the test code stay synchronous and the timeout logic stays simple.

Two real lines. await page.context().setOffline(true); for the network flip (emitted by the official @playwright/mcp browser_network_state_set tool), and a wait that you decide to translate as either await page.waitForSelector('text=You are offline') if you have a stable selector or a custom DOM-mutation poll if you do not. Assrt's run trace at /tmp/assrt/results/latest.json contains both, plus a screenshot of the page after navigator.onLine flipped to false.

Yes for the navigator.onLine getter on the page main world. No for arbitrary effects on the page. The promise resolves once Playwright has sent Network.emulateNetworkConditions { offline: true } over CDP and Chromium has acknowledged it. Your offline event listener fires shortly after, on the next tick. But your React component that re-renders to show an offline banner depends on your own state machine and could take 10ms or 300ms. wait_for_stable is what bridges that gap.

Yes, the technique is portable. Inject window.__mut_count = 0 and a MutationObserver in a page.evaluate, then poll page.evaluate(() => window.__mut_count) on a setInterval until the value stabilizes for your quiet period. Assrt ships this as a tool because the agent needs a deterministic 'is the page done reacting' signal, but you can lift the same 50 lines of logic out of agent.ts:941-994 into a helper and use it in your own *.spec.ts. No Assrt runtime required.

Not unless you patched it via addInitScript before SW registration. context.setOffline(true) flips the page target's offline flag in CDP but historically does not propagate to the service worker target (microsoft/playwright#2311). wait_for_stable measures DOM mutations regardless. If your offline UI depends on the SW returning a cached page, the SW will return the live response, and wait_for_stable will return successfully because the DOM did stabilize, just not in the offline state you expected. This is a Playwright gap, not an Assrt one.