In a Next.js 16 App Router app with `cacheComponents: true`, after a client-side navigation (Link, router.push, redirect from a server action) the previous route is not unmounted: React keeps it in the DOM inside a hidden `<Activity>` (display:none), and its effects are cleaned up while hidden. A browser test that uses `document.querySelector(...)` may then match the hidden copy instead of the visible page. Typical symptom: a status element stuck on "Loading…" / "Calcul…" with no network request ever sent, because the hidden copy's debounced effect timer was cleared when it was hidden. It looks like an intermittent bug in the visible page, but the visible component works. Duplicate `role=status`, duplicate ids from `useId`-free code, or duplicate `[data-*]` hooks also appear.

When driving a real Chromium-based browser over the DevTools Protocol for UI tests while the machine's display is asleep (or the window occluded), document.visibilityState is "hidden". Pages rendered with React 19 streaming SSR (Next.js App Router, Suspense boundaries) stay stuck on the Suspense fallback forever: the streamed HTML is present in hidden divs, but never swapped in and never hydrated. No console error is shown.

When testing a third-party embeddable JS snippet (tracker, widget) from a fake site served by `python -m http.server`, after changing the script the browser keeps running the OLD version: the static HTML pages are heuristically cached (Last-Modified, no Cache-Control) and the script itself is served with public max-age. Tests then show behavior of the previous version and look like a regression.

If you drive a modern React signup or login flow through a raw Chrome DevTools Protocol client (no Playwright), you hit several silent failures. el.click() from Runtime.evaluate does nothing on some submit buttons. Input.insertText on a 6-box one-time-code input leaves every box empty. Input.dispatchKeyEvent calls hang or take 30+ seconds. And after a click that triggers a client-side transition, reading the page right away still shows the old step, so you think the submit failed and act again.

When you use Brave with --remote-debugging-port to observe how a third-party analytics or tracking script behaves (cookies, beacons, consent flow), the script often looks like it does nothing: the command queue array is never consumed, no tracking cookies appear and no beacon requests leave. There is no console error. Two separate Brave defaults cause this: Shields blocks the tracker script, and Global Privacy Control (Sec-GPC header plus navigator.globalPrivacyControl=true) makes compliant consent managers treat the visitor as opted out.