Changing URL hash causes entire page to reload

[Andrew-web-coder]

Describe the bug

Changing URL hash causes entire page to reload. This causes issues with third part script that uses hash navigation (well, it is Fancybox, but it is not relevant, you can quickly observe that by yourself).

Reproduction

1. Go to https://vitepress.vuejs.org
2. Resize window so that vertical scrollbar appears, scroll to the bottom
3. Change URL to https://vitepress.vuejs.org#aa
4. Watch as entire page reloads

Expected behavior

The page should not reload

System Info

System:
    OS: Windows 10 10.0.19044
    CPU: (8) x64 Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
    Memory: 6.77 GB / 15.95 GB
  Binaries:
    Node: 18.12.1 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.5 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 9.2.0 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 109.0.5414.74
    Edge: Spartan (44.19041.1266.0), Chromium (108.0.1462.76)
    Internet Explorer: 11.0.19041.1566

Additional context

No response

Validations

• Follow our Code of Conduct
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.

[brc-dd]

This depends on how you're changing the url. If you're directly changing the URL from browser, obviously it will reload. If you're changing the route programmatically, then you need to use the exposed router (useRouter()) for SPA navigation. For links (bare anchor tags without target and absolute url or file extension other than html specified), it should work fine (unless you're pressing some meta key while clicking that link). Feel free to reopen if the last one is what you're having issues with.

[Andrew-web-coder]

The thing is - Docusaurus, for example, works perfectly fine with Fancybox, but Vitepress does not, simply because it reloads on hash change, when navigating using back/forward button or changing URL manually.

I do not understand your comment - "obviously it will reload". Steps to reproduce on Docusaurus:

1. Go to https://docusaurus.io/ and sroll to the bottom.

2. Change url to https://docusaurus.io/#aaa - observe that nothing reloads, vertical page scroll position stays the same, everything works fine as expected.

3. Press back button on the browser - URL changes back to https://docusaurus.io/ and nothing reloads or scrolls, as expected.

4. Press forward button on the browser - URL changes back to https://docusaurus.io/#aaa and, again, nothing reloads or scrolls, as expected.

So, I am sure there is a difference between React and Vue routing, and I would like to make Vitepress to work the same as Docusaurus.

[brc-dd]

Ah, this works on VuePress too 👀 . But VuePress/Docusaurus have probably much more complex router. Our router only intercepts certain kind of stuff, browser does the most of the thing.

PS: if you just want fancybox for zooming images, the workarounds mentioned here might work #854

[Andrew-web-coder]

Yes, you are right, VuePress works the way I want. If Vitpress worked the same way, then anyone using a third part scripts with hash navigation would benefit.

p.s. I already use Fancybox on my main site, I just wanted to create a documentation site and use it here as well. It works well if I disable Hash plugin, but I would like to avoid doing that.

p.p.s I love Vite and VitePress, thank you all for your great work!

[Andrew-web-coder]

FYI, I hacked the VitePress source code for fun and found this problem to be very easy to fix. So, the problem is here:
https://github.com/vuejs/vitepress/blob/main/src/client/app/router.ts#L182

window.addEventListener('popstate', (e) => {
    loadPage(location.href, (e.state && e.state.scrollPosition) || 0)
})

As you can see, VitePress loads page every time the user navigates using the browser's back/forward buttons. I added a simple check to avoid reloading current page. I could not find out how to get location of previous page, so I created a global variable and stored href value within go and loadPage methods. Then I simply compare it with the current location and load page only if different. Now everything is working amazingly well for me.

[brc-dd]

There are now router guards that should be sufficient for these cases. Refer #2564