Bug 312861 – REGRESSION: PerformanceNavigationTiming.domInteractive and domContentLoadedEventEnd always return 0

• Component: Page Loading
• Status: RESOLVED FIXED

Overview:
PerformanceNavigationTiming.domInteractive and domContentLoadedEventEnd return 0 instead of the correct elapsed time since navigation start. loadEventEnd returns the correct value. The deprecated performance.timing equivalents work correctly.

Steps to Reproduce:

Open any page in Safari (e.g. https://example.com)
Open Web Inspector → Console
Run:

const nav = performance.getEntriesByType('navigation')[0];
console.log('domInteractive:', nav.domInteractive);
console.log('domContentLoadedEventEnd:', nav.domContentLoadedEventEnd);
console.log('loadEventEnd:', nav.loadEventEnd);
Actual Results:
domInteractive and domContentLoadedEventEnd both log 0. loadEventEnd logs the correct value (e.g. 137).

Expected Results:
All three fields should return elapsed milliseconds since navigation start (e.g. domInteractive: 120, domContentLoadedEventEnd: 145, loadEventEnd: 137). This matches the behaviour of Chromium and Firefox, and matches what the deprecated performance.timing API returns in WebKit itself.

Build Date & Hardware:
Safari 26.4 (WebKit 21624.1.16.11.4), macOS 26.4.1, Apple Silicon.

Additional Builds and Platforms:
Does not occur in Chrome or Firefox. Regression is WebKit-only.

Confirmed affected on:

macOS 26.4.1 (Apple Silicon), Safari 26.4 (WebKit 21624.1.16.11.4)
Debian 12 (x64)

Additional Information:
Bisecting Playwright's dated WebKit builds (which use snapshots of WebKit upstream) places the regression between WebKit revisions 2266 (working) and 2267 (broken), corresponding to a WebKit upstream snapshot from approximately late January / early February 2026.

Preliminary analysis: Document::setReadyState(Interactive) in Document.cpp calls documentEventTimingFromNavigationTiming() to write the domInteractive timestamp into the PerformanceNavigationTiming entry. This function requires window->performance().navigationTiming() to be non-null. A change in the ordering of addNavigationTiming() relative to setReadyState(Interactive) appears to have caused m_navigationTiming to be null at that point, so the timestamp is never recorded. The legacy PerformanceTiming path writes directly to m_eventTiming and is unaffected.

[Karl Dubost]

Safari Technology Preview 242
domInteractive: – 0
domContentLoadedEventEnd: – 0
loadEventEnd: – 45

Firefox Nightly 151.0a1 
domInteractive: 520 
domContentLoadedEventEnd: 522 
loadEventEnd: 526 


 Chrome Canary 149.0.7811.0
domInteractive: 654.3999999761581
domContentLoadedEventEnd: 654.3999999761581
loadEventEnd: 662.7999999523163

[Karl Dubost]

Maybe this is related to a change by Chris?
https://github.com/WebKit/WebKit/commit/cf994a7e92ba1e6f0fd32f5eaf94b96b10c658b3

[Radar WebKit Bug Importer]

<rdar://problem/175739835>

[Chris Dumez]

Pull request: https://github.com/WebKit/WebKit/pull/64139

[EWS]

Committed 312500@main (2d4afb4d2ec5): <https://commits.webkit.org/312500@main>

Reviewed commits have been landed. Closing PR #64139 and removing active labels.