Clicking hash link twice on Firefox breaks back navigation

[teemingc]

Describe the bug

This issue only occurs when using the desktop Firefox browser.

Clicking a hash link twice then navigating to a new page causes the browser back navigation to change the URL but no navigation occurs.

Reproduction

https://stackblitz.com/edit/github-lxdc8e?file=src%2Froutes%2F%2Blayout.svelte

1. Preview the website in a desktop Firefox browser.
2. On the same page, click the "Go to footer" hash link twice.
3. Navigate to a different page.
4. Press the browser back button.
5. The browser does not navigate back but the URL changes.

Logs

No response

System Info

System:
    OS: macOS 13.2
    CPU: (8) arm64 Apple M1 Pro
    Memory: 3.76 GB / 32.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 16.18.0 - ~/.nvm/versions/node/v16.18.0/bin/node
    Yarn: 3.2.3 - ~/.nvm/versions/node/v16.18.0/bin/yarn
    npm: 8.19.2 - ~/.nvm/versions/node/v16.18.0/bin/npm
  Browsers:
    Chrome: 109.0.5414.87
    Chrome Canary: 111.0.5559.0
    Firefox: 109.0
    Firefox Developer Edition: 105.0
    Safari: 16.3
    Safari Technology Preview: 16.4
  npmPackages:
    @sveltejs/adapter-auto: ^1.0.0 => 1.0.2 
    @sveltejs/kit: ^1.0.0 => 1.2.8 
    svelte: ^3.54.0 => 3.55.1 
    vite: ^4.0.0 => 4.0.4

Severity

serious, but I can work around it

Additional Information

No response

[danielimmke]

If no one is looking at this, I can take it.

[dummdidumm]

Sure, go ahead!

[teemingc]

One potential cause of this is that Firefox does not emit a popstate event on subsequent navigations to the same hash URL. However, Chrome and Safari will always emit the popstate event.

[danielimmke]

Spent some time on this today, I was able to confirm what @s3812497 said. Firefox's popState event also doesn't include all of the same information as Chrome's.

I think it will be a matter of finding where in the routing code SvelteKit decides to "navigate" and changing the conditional logic to account for this. I can only work on this in small increments but have some additional time planned for it this coming week.

[danielimmke]

I'm sorry, I just don't have the bandwidth to look at this further right now. Hopefully the little bit I did helped.

[teemingc]

I'm sorry, I just don't have the bandwidth to look at this further right now. Hopefully the little bit I did helped.

No worries! Thanks for the extra info that you've put out. I'll try and have a look at it again this weekend :)

[teemingc]

@Rich-Harris how are we populating event.state with the sveltekit:index key on any popstate event? I can't find it in the codebase myself. Firefox is always returning null for it in this scenario, causing back navigation to break, while Chrome is always returning it populated.

kit/packages/kit/src/runtime/client/client.js

Lines 1620 to 1624 in 526a2ed

	addEventListener('popstate', async (event) => {
	if (event.state?.[INDEX_KEY]) {
	// if a popstate-driven navigation is cancelled, we need to counteract it
	// with history.go, which means we end up back here, hence this check
	if (event.state[INDEX_KEY] === current_history_index) return;

[trueadm]

So looking more into this, and it seems when you click a link with a hash, hashchange fires, where we do replaceState. However, in Firefox, clicking a link with the same hash will not trigger hashchange and instead will set history.state to null. Looking at how other routing solutions handle this is interesting – they don't seem to use hashchange, and instead always push on hash changes. We could do something similar here, or we could detect FF and force a state change.

[Rich-Harris]

Could we somehow detect that the hashchange is a direct result of the replaceState rather than UA sniffing?

@Rich-Harris how are we populating event.state with the sveltekit:index key on any popstate event?

I'm not sure I understand? It's populated at the time of the pushState or replaceState that created the history entry we're popping to.

[trueadm]

Could we somehow detect that the hashchange is a direct result of the replaceState rather than UA sniffing?

Not sure this would solve the issue. If you refresh a link with a hash and click the same link with the hash, you don't get a hashchange and you don't get a popstate. You only get the click handling logic. Maybe we can detect if history.state is null at this point? I'll do some more digging.