You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Safari Private Browsing (macOS 26.3.1 / iOS 26.4), routing breaks: the URL bar changes after a link click but the page content stays the old one. Reloading restores correct rendering.
Root cause
WebKit Private Browsing appears to have a bug in the Navigation API implementation: after event.intercept({ handler }) commits an intercepted navigation, navigation.currentEntry continues to point to the previous entry (both .url and .id are stale) and currententrychange does not fire. Only location.href and navigatesuccess reflect the new URL.
Repro: open https://router.funstack.work/ in macOS Safari Private and click any nav link. The URL bar updates, content does not.
2026-05-17.23.53.18.mov
Options
Stay spec-aligned
Keep reading navigation.currentEntry.url. SPA routing remains broken in Safari Private Browsing until WebKit ships a fix. Pros: no workaround code. Cons: end users on Safari Private see broken routing in the meantime.
Browser-specific workaround in the adapter
In NavigationAPIAdapter, treat location.href as the authoritative URL and subscribe to navigatesuccess in addition to currententrychange. Loader cache key extended to include the resolved URL so stale loader results are not served. Pros: restores URL-based routing in Safari Private Browsing while preserving current behavior elsewhere. Cons: a browser-specific workaround sits in the adapter until WebKit fixes the bug. Some currentEntry-dependent features (notably route state via entry.getState()) can still be wrong in Private mode only URL routing is restored by this approach.
Proposal
My preference is 2, because the failure mode is user-visible and the workaround can be isolated to NavigationAPIAdapter with a clearly marked comment block.
I'm filing this as an issue first because this is a project policy choice strict Navigation API semantics versus carrying a browser specific workaround and I'd like to defer to your direction before opening a PR. If you'd prefer 1, this issue can be closed; if you'd prefer 2 (or a third approach), I'm happy to open a PR.
Symptom
In Safari Private Browsing (macOS 26.3.1 / iOS 26.4), routing breaks: the URL bar changes after a link click but the page content stays the old one. Reloading restores correct rendering.
Root cause
WebKit Private Browsing appears to have a bug in the Navigation API implementation: after
event.intercept({ handler })commits an intercepted navigation,navigation.currentEntrycontinues to point to the previous entry (both.urland.idare stale) andcurrententrychangedoes not fire. Onlylocation.hrefandnavigatesuccessreflect the new URL.Repro: open
https://router.funstack.work/in macOS Safari Private and click any nav link. The URL bar updates, content does not.2026-05-17.23.53.18.mov
Options
Stay spec-aligned
Keep reading
navigation.currentEntry.url. SPA routing remains broken in Safari Private Browsing until WebKit ships a fix. Pros: no workaround code. Cons: end users on Safari Private see broken routing in the meantime.Browser-specific workaround in the adapter
In
NavigationAPIAdapter, treatlocation.hrefas the authoritative URL and subscribe tonavigatesuccessin addition tocurrententrychange. Loader cache key extended to include the resolved URL so stale loader results are not served. Pros: restores URL-based routing in Safari Private Browsing while preserving current behavior elsewhere. Cons: a browser-specific workaround sits in the adapter until WebKit fixes the bug. SomecurrentEntry-dependent features (notably route state viaentry.getState()) can still be wrong in Private mode only URL routing is restored by this approach.Proposal
My preference is 2, because the failure mode is user-visible and the workaround can be isolated to
NavigationAPIAdapterwith a clearly marked comment block.I'm filing this as an issue first because this is a project policy choice strict Navigation API semantics versus carrying a browser specific workaround and I'd like to defer to your direction before opening a PR. If you'd prefer 1, this issue can be closed; if you'd prefer 2 (or a third approach), I'm happy to open a PR.