312861 2026-04-21 01:10:00 -0700 REGRESSION: PerformanceNavigationTiming.domInteractive and domContentLoadedEventEnd always return 0 2026-05-03 21:19:53 -0700 1 1 1 Unclassified WebKit Page Loading WebKit Nightly Build Mac (Apple Silicon) macOS 26 RESOLVED FIXED InRadar P2 Major --- 1 p.majer cdumez beidson cdumez karlcow webkit-bug-importer oldest_to_newest 2202602 0 p.majer 2026-04-21 01:10:00 -0700 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. 2204807 1 karlcow 2026-04-27 01:20:41 -0700 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 2204828 2 karlcow 2026-04-27 02:13:55 -0700 Maybe this is related to a change by Chris? https://github.com/WebKit/WebKit/commit/cf994a7e92ba1e6f0fd32f5eaf94b96b10c658b3 2205287 3 webkit-bug-importer 2026-04-28 01:10:12 -0700 <rdar://problem/175739835> 2207058 4 cdumez 2026-05-03 18:34:19 -0700 Pull request: https://github.com/WebKit/WebKit/pull/64139 2207081 5 ews-feeder 2026-05-03 21:19:50 -0700 Committed 312500@main (2d4afb4d2ec5): <https://commits.webkit.org/312500@main> Reviewed commits have been landed. Closing PR #64139 and removing active labels.