[Bug]: clock.resume() causes NS_ERROR_NOT_INITIALIZED in Firefox on Linux

[7rulnik]

Version

1.58.2

Steps to reproduce

This is a timing-dependent race condition that reproduces reliably in CI (Linux Firefox in Docker) but I was unable to create a minimal standalone reproduction. I can provide a full trace from CI if needed.

Setup:

1. page.clock.install({ time: <date> })
2. page.clock.resume()
3. Navigate to a page with interactive UI
4. Click elements that trigger DOM re-renders (e.g. dropdown selection)

It does not affect Chromium or WebKit.
Does not reproduce on macOS Firefox.
I also could not reproduce it using macOS and same docker image via PW_TEST_CONNECT_WS_ENDPOINT

Expected behavior

page.clock.resume() should not cause errors during normal page interactions.

Actual behavior

Console errors appear repeatedly during UI interactions:

  [JavaScript Error: "NS_ERROR_NOT_INITIALIZED: " {file: "debugger eval code" line: 557}]

and then page becomes blank.

Line 557 of the injected clock source maps to originals.bound.setInterval(task, delay) in the createClock() embedder: https://github.com/microsoft/playwright/blob/b1de1702b/packages/injected/src/clock.ts#L772-L774

Called by _updateRealTimeTimer() — the real-time sync loop started by clock.resume(): https://github.com/microsoft/playwright/blob/b1de1702b/packages/injected/src/clock.ts#L232-L251

NS_ERROR_NOT_INITIALIZED is thrown by Firefox's nsGlobalWindowInner::SetTimeoutOrInterval when the window's JS context is gone or the window was already closed: https://github.com/mozilla-firefox/firefox/blob/fb4975f0/dom/base/nsGlobalWindowInner.cpp#L6480-L6484

if (!GetContextInternal() || !HasJSGlobal()) {
    // This window was already closed, or never properly initialized,
    // don't let a timer be scheduled on such a window.
    aError.Throw(NS_ERROR_NOT_INITIALIZED);
    return 0;
}

Both window.setTimeout (https://github.com/mozilla-firefox/firefox/blob/fb4975f0/dom/base/nsGlobalWindowInner.cpp#L6444-L6449) and window.setInterval (https://github.com/mozilla-firefox/firefox/blob/fb4975f0/dom/base/nsGlobalWindowInner.cpp#L6452-L6457) go through
this path.

The clock's real-time sync loop (_updateRealTimeTimer) holds bound references to the original native setTimeout/setInterval. When the window's context becomes unavailable, the next sync tick throws.

From the trace, the error fires during normal UI interactions on a fully loaded page (~3s after clock.resume()), specifically during click actions that trigger DOM re-renders:

  73063ms  BrowserContext.clockInstall
  73083ms  BrowserContext.clockResume
  73097ms  Frame.goto
  75836ms  Frame.click                     (dropdown option)
  76172ms  ... performing click action
  76220ms  ** NS_ERROR_NOT_INITIALIZED at debugger eval code:557 **
  76282ms  ... click action done
  76861ms  ** NS_ERROR_NOT_INITIALIZED at debugger eval code:557 **
  76917ms  ** NS_ERROR_NOT_INITIALIZED at debugger eval code:557 **

Raw console event from trace:

  {
    "type": "console",
    "messageType": "error",
    "text": "[JavaScript Error: \"NS_ERROR_NOT_INITIALIZED: \" {file: \"debugger eval code\" line: 557}]",
    "location": { "lineNumber": 557, "columnNumber": 39, "url": "debugger eval code" }
  }

Additional context

I can upload full trace if needed

Environment

System:
    OS: Linux 6.12 Debian GNU/Linux 12 (bookworm) 12 (bookworm)
    CPU: (32) x64 AMD EPYC 7R13 Processor
    Memory: 240.93 GB / 246.56 GB
    Container: Yes
  Binaries:
    Node: 24.13.0 - /usr/local/bin/node
    Yarn: 4.12.0 - /usr/local/bin/yarn
    npm: 11.6.2 - /usr/local/bin/npm
  Languages:
    Bash: 5.2.15 - /usr/bin/bash
  npmPackages:
    @playwright/test: 1.58.2 => 1.58.2

[Skn0tt]

Hi! Did this also occur on earlier Playwright versions, and does it occur on Playwright 1.59?

[7rulnik]

I will check 1.59 tomorrow. But we just started to use playwright. How earlier version it make sense to try?

[pavelfeldman]

I'll close this as having no repro, our template makes it clear - we need a local repro we can just run, fix and include as a test. Click elements that trigger DOM re-renders (e.g. dropdown selection) is unclear and not reproducible.

[7rulnik]

Well, I understand that. But sometimes repro is not a easiest thing. I spent already 2 days trying to reproduce it.

Also I tried to bisect playwright and looks like it was introduced in #37705