Page store does not changing on history back

[davydhyk]

Describe the bug

Page store does not trigger change when navigate to hash url and use history back. In presented code fragment on each hash change needs to be 2 logs ($page object and HashChangeEvent), but sometimes logs only one record with event and store stays unchaged.

Reproduction

<script>
  import { page } from '$app/stores';
  
  $: console.log($page);
</script>

<svelte:window on:hashchange={console.log}/>

<button on:click={() => history.back()}>back</button>
<a href="#hash">hash</a>

Logs

No response

System Info

System:
    OS: Linux 5.10 Ubuntu 20.04.4 LTS (Focal Fossa)
    CPU: (12) x64 AMD Ryzen 5 2600 Six-Core Processor
    Memory: 10.99 GB / 12.44 GB
    Container: Yes
    Shell: 5.0.17 - /bin/bash
  Binaries:
    Node: 16.14.0 - ~/.nvm/versions/node/v16.14.0/bin/node
    npm: 8.5.4 - ~/.nvm/versions/node/v16.14.0/bin/npm
  npmPackages:
    @sveltejs/adapter-auto: next => 1.0.0-next.31 
    @sveltejs/adapter-node: ^1.0.0-next.73 => 1.0.0-next.73 
    @sveltejs/kit: next => 1.0.0-next.295 
    svelte: ^3.46.0 => 3.46.4

Severity

serious, but I can work around it

Additional Information

No response

[rmunn]

Confirmed with version next.308 of Svelte-Kit.

BTW, I did some console.log debugging and found something interesting. If you add another link to the page: <a href="/">no hash</a> then the behavior changes quite a bit.

Scenario 1

• Load page
• Click on "hash" link, going to http://localhost:3000/#hash
  • $page store subscription fires, logging http://localhost:3000/#hash
• Click on "back" button inside page, returning to http://localhost:3000/
  • $page store subscription does not fire

This is the same as the scenario that OP mentioned.

Scenario 2

• Load page
  • $page store subscription fires, logging http://localhost:3000/
• Click on "no hash" link (going to http://localhost:3000/ which is current URL)
  • $page store subscription does not fire
• Click on "hash" link, going to http://localhost:3000/#hash
  • $page store subscription fires, logging http://localhost:3000/#hash
• Click on "back" button inside page, returning to http://localhost:3000/
  • $page store subscription does not fire

Same behavior as scenario 1: clicking the "no hash" link while on that URL had no effect.

Scenario 3

• Load page
  • $page store subscription fires, logging http://localhost:3000/
• Click on "hash" link
  • $page store subscription fires, logging http://localhost:3000/#hash
• Click on "no hash" link (going to http://localhost:3000/ which is NOT the current URL)
  • $page store subscription does not fire
• Click on "back" button inside page, returning to http://localhost:3000/#hash
  • $page store subscription fires, logging http://localhost:3000/#hash
• Click on "back" button inside page, returning to http://localhost:3000/
  • $page store subscription fires(!), logging http://localhost:3000/

This behavior is different from scenarios 1 and 2. By clicking on an <a> link that went from /#hash to /, we have changed when the bug occurs. Instead of occurring on clicking the "back" button, it occurs on clicking the "no hash" link.

So is history.back() really the cause of the issue? Or does it always fire on the next navigation after clicking a link with a hash? I'll need to do more debugging, and I'm out of time to do so today, but that's suspicious.

[PH4NTOMiki]

Possibly related #3975 (comment)

[davydhyk]

I made some research and can say that your predictions are right - history.back() is not a reason of the issue.

It happens due to #3177.
The reason is the changing of field Client.current that holds current url, but #3177 preventing router navigation and Client.current leaves unchanged. When you click on the same link that before hash change this causes an issue.

history.back() history.forward() always trigger router navigation and breaks on first click on hashlink but restore after few actions (back, forward)

[PH4NTOMiki]

@Rich-Harris can you take a look?

[flut1]

This is somewhat related to #2673

I wanted to update the URL without fetching the page route again, as described in #2673 . As a temporary workaround, I tried changing the hash fragment instead. I ran into the same problem as described here. As mentioned above, the internal current state of the client is not updated properly. Additionally, I think the url property of stores.page would need to be updated internally.

So I think if there was a way to update the internal url of the client without triggering navigation, it can serve as a solution to both these issues.

[dummdidumm]

No longer reproducible.