fix: emit hashchange events with view transitions

[destruc7i0n]

Changes

• With View Transitions, hashchange events are now emitted when navigating between hash anchors on the same page (e.g., clicking anchor links)
• The event includes oldURL and newURL properties matching standard browser behavior
• This behaviour is useful for apps like documentation sites, where we want to sync the highlighted element on the sidebar to the hash.

Testing

• Added three new e2e tests in view-transitions.test.js:
  • Test that hashchange fires for same-page hash navigation
  • Test that hashchange fires for back/forward navigation with hashes
  • Test that hashchange does NOT fire for cross-page navigation

Docs

I don't think any are required. This implements standard browser behavior that developers already expect.

[changeset-bot]

🦋 Changeset detected

Latest commit: 2d29da4

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codspeed-hq]

CodSpeed Performance Report

Merging #14746 will not alter performance

_{Comparing destruc7i0n:main (2d29da4) with main (00c579a)¹}

Summary

✅ 6 untouched

Footnotes

1. No successful run was found on main (ac4f3ac) during the generation of this report, so 00c579a was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[martrapp]

Hi @destruc7i0n 👋🏼

Thank you for opening this PR!
I wasn't aware that history.pushState() or history.replaceState() won't dispatch the hashchange event.

[martrapp]

Without the client router, a navigation from /long-page#click-one-again to /long-page won't dispatch a hashchange event.

Also doing a history backward traversal from /long-page to /long-page#click-one-again won't dispatch the event.

To mimic standard browser behavior that developers already expect, we should exclude the event for a navigation to an URL without fragment identifier and for backward traversal from an URL without fragment identifier? 🤓

[destruc7i0n]

Hmm true. Seems like the browser itself is emitting a hashchange event with the backwards traversal from /long-page to /long-page#click-one-again so I'll need to take a look at how to stop that 🤔