Can't navigate back from a path with hash and data-sveltekit-reload

[unleashy]

Describe the bug

If you click on a link of a #hash, and then go to a new page, and then press back to go back to that page, nothing happens.

This only seems to happen if the link includes data-sveltekit-reload. Without that, everything works fine.

Taking out data-sveltekit-reload isn't a solution because there's another (less bad) bug: if your current path is already #hash, when you click on a link to #hash, scroll moves to the linked-to element (great) but it is not focused at all (nooo).

Reproduction

https://stackblitz.com/edit/sveltejs-kit-template-default-nyxdxa?file=src%2Froutes%2Fa%2F%2Bpage.svelte

1. Click on link A, going to a new page.
2. Click on link B, uses hash to focus on input.
3. Click on link C, going to a new page.
4. Press ← on browser to go back (or with side mouse button if you have that)—won't work, page stays put.

Note that it doesn't matter what the hash points to, it can be anything, I just used an input because it's clearer because the input becomes focused as a clear indication the hash is working.

Logs

No response

System Info

I mean, it happens on Stackblitz. But here it is for my specific project:

  System:
    OS: Windows 11 10.0.22631
    CPU: (8) x64 Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
    Memory: 11.47 GB / 23.85 GB
  Binaries:
    Node: 20.10.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 4.0.2 - C:\Program Files\nodejs\yarn.CMD
    npm: 10.2.5 - C:\Program Files\nodejs\npm.CMD
    pnpm: 9.0.6 - C:\Program Files\nodejs\pnpm.CMD
  Browsers:
    Chrome: 124.0.6367.119
    Edge: Chromium (123.0.2420.97)
    Internet Explorer: 11.0.22621.1
  npmPackages:
    @sveltejs/adapter-auto: ^3.2.0 => 3.2.0
    @sveltejs/adapter-node: ^5.0.1 => 5.0.1
    @sveltejs/kit: ^2.5.7 => 2.5.7
    @sveltejs/vite-plugin-svelte: ^3.1.0 => 3.1.0
    svelte: 5.0.0-next.120 => 5.0.0-next.120
    vite: ^5.2.10 => 5.2.11

Severity

serious, but I can work around it

Additional Information

Sorry if this is a duplicate of #10234, I couldn't really seem to figure out if it is the same bug or not, but it doesn't seem like it because disabling preloading doesn't seem to change anything in my testing. Couldn't find any other issues mentioning a similar bug either.