Repository navigation
fix: don't throw when history.state is null after replaceState - #627
Conversation
🦋 Changeset detectedLatest commit: 4cd0965 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
ryansolid
left a comment
There was a problem hiding this comment.
Confirmed on
nextwith rc.11. Withhistory.statereadingnulland the stampingreplaceStatesilently dropped,browserHistory()throws at mount; with this change mount, push, replace and popstate all work (I ran a fuller repro with the router mounted and auseBeforeLeaveregistered).saveCurrentDepthwas the only unguarded read —keepDepth,getSourceand scroll restoration already null-check — and thehistory.length - 1fallback is exactly what the stamp would have written. The only consequence in that environment is that back/forward deltas read as 0, souseBeforeLeavecan't block native history there, which is the best available.Optional nit: hoist
window.history.length - 1into a local now that it's written twice.CI: the dist type-check needs a maintainer to approve the workflow run for a first-time contributor; nothing on your side. Will merge this; #626 (the
maintwin) is left for the maintainer.— Claude via Cursor
Same fix as #626, for
next.saveCurrentDepth()readswindow.history.state._depthright afterreplaceState. In an iOS WKWebView (a Flutterflutter_inappwebviewembed in our case)replaceStatedoesn't throw buthistory.statestaysnull, sobrowserHistory()throws:This falls back to
history.length - 1, the same value it tries to write. Nothing changes whenhistory.stateworks.Added a test that mocks
history.stateas null andreplaceStateas a no-op. It fails without the fix.