[vike@0.4.201][Bug] You stumbled upon a Vike bug.
Closed this issue · 20 comments
Are you, or one of your libraries, using history.pushState()
or history.replaceState()
?
Maybe Swiper.js does such things under the hood. It is used to display swipeable cards linking to other pages. If so should I seek to override to change the logic to something else?
Any history.pushState()
/history.replaceState()
call should called after Vike monkey patches both.
Keep us updated. At least the error message should be improved.
I've created repository based on sample Vike page at the repository here https://github.com/Plajer/vike-issue-1962
The issue is located in pages/star-wards/index/+Page.tsx
When Vike issue test
anchor pointing towards # is clicked and scroll is done through page (made 200vh on div to do so) the error appears.
The issue wasn't related to external libraries using history API.
Can you make the repo public? I get a 404.
Pardon me, it's public now.
When
Vike issue test
anchor pointing towards # is clicked and scroll is done through page (made 200vh on div to do so) the error appears.
I cannot reproduce. What steps exactly lead to the error?
Actually, it seems to be a race condition and I think I found what causes it. I pushed a fix and pre-released it as 0.4.203-commit-1b14559
. Let me know if you still get the error (if you do I'll re-open).
Use 0.4.203-commit-1b14559
(the previous pre-release contained a regression).
I still do have the error in version vike@0.4.203-commit-1b14559
.
[vike@0.4.203-commit-1b14559][Bug] You stumbled upon a Vike bug. Go to https://github.com/vikejs/vike/issues/new and copy-paste this error. A maintainer will fix the bug (usually under 24 hours).
createErrorWithCleanStackTrace createErrorWithCleanStackTrace.js:4
assert assert.js:54
getState history.js:52
saveScrollPosition history.js:68
onPageHide onPageVisibilityChange.js:6
onPageHide onPageVisibilityChange.js:4
autoSaveScrollPosition setScrollPosition.js:76
initHistoryAndScroll initClientRouter.js:34
initClientRouter initClientRouter.js:12
<anonymous> entry.js:10
Worth noting that this issue doesn't occur at Chrome 131 but does on Firefox 131 and Firefox Developer Edition 133.0b9.
I can reproduce and I see what's going on. It's a Firefox bug, let me try to find a workaround.
Reproduction steps: click on the #
link (Vike issue test
) twice then scroll down. Observe how Firefox erroneously sets window.history.state
to null
(without firing any signal that we can detect).
Fix released in 0.4.204
.
Looks like the issue still persists, and no need to click # twice, just once does still make the issue appear.
When starting from page with # there is no error condition but when starting without it will appear.
Did you remove Vite's cache rm -r node_modules/.vite
?
I cannot reproduce using following steps:
- Update to
vike@0.4.204
- Open http://localhost:3000/star-wars in a new tab (so that the browsing history is empty)
- Click on
Vike issue test
- Scroll down
I don't see any error in the browser's dev console. Using Firefox 132.0.1
.
Can confirm having latest version. Works well on Firefox 132 but issue persists on Firefox Developer Edition 133.0b9 but not on every page refresh, might be an issue or regression of a beta preview then.
I assume it's a separate issue so having an error stack trace would be helpful.
Or let's try again with 133 once it has a stable release.
The stack trace is:
[vike@0.4.204][Bug] You stumbled upon a Vike bug. Go to https://github.com/vikejs/vike/issues/new and copy-paste this error. A maintainer will fix the bug (usually under 24 hours).
createErrorWithCleanStackTrace createErrorWithCleanStackTrace.js:4
assert assert.js:54
getState history.js:53
saveScrollPosition history.js:69
onPageHide onPageVisibilityChange.js:6
onPageHide onPageVisibilityChange.js:4
autoSaveScrollPosition setScrollPosition.js:94
initHistoryAndScroll initClientRouter.js:34
initClientRouter initClientRouter.js:12
<anonymous> entry.js:10
Hm, seems like a similar issue where Firefox erroneously sets history.state
to null
.
I added some debug logs. Let's further dig if we can reproduce on a stable Firefox version.