kit: Scrolling to hash links is broken on Chrome

Describe the bug

Clicking a link like https://kit.svelte.dev/docs/configuration#version should take you to that part of the page. It works in Firefox…

…but not Chrome:

Reproduction

Go to https://kit.svelte.dev/docs/configuration#version in Chrome

Logs

No response

System Info

System:
    OS: macOS 12.0.1
    CPU: (10) arm64 Apple M1 Max
    Memory: 69.61 MB / 32.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.13.1 - ~/.nvm/versions/node/v16.13.1/bin/node
    Yarn: 1.22.17 - ~/.nvm/versions/node/v16.13.1/bin/yarn
    npm: 8.1.2 - ~/.nvm/versions/node/v16.13.1/bin/npm
  Browsers:
    Chrome: 98.0.4758.109
    Firefox: 97.0.1
    Safari: 15.1
  npmPackages:
    @sveltejs/adapter-auto: next => 1.0.0-next.30 
    @sveltejs/adapter-static: next => 1.0.0-next.28 
    @sveltejs/kit: next => 1.0.0-next.291 
    svelte: ^3.46.0 => 3.46.4

Severity

annoyance

Additional Information

No response

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 29 (21 by maintainers)

Commits related to this issue

workaround #4216 — committed to sveltejs/kit by Rich-Harris 2 years ago
Workaround hydration scrolling bug (#4221) * use src version locally * workaround #4216 * reimplement banner — committed to sveltejs/kit by Rich-Harris 2 years ago

Most upvoted comments

Just wanted to tell you guys, you are doing great job, I recently tried svelte (kit) and felt like am home 🚀 ( no jsx, simplicity, chrome lighthouse is very happy …etc) I want to help with this but am still a noob, am learning a lot reading what you’re doing guys. Keep it up.

And good luck with this scrolling bug 😊

benzara-tahar on Mar 4, 2022

Hash links are working fine for me in Chrome Version 99.0.4844.84 on a Mac. Am I supposed to do something in particular to reproduce the issue?

https://kit.svelte.dev/docs/configuration#version

cliftonlabrum on Apr 5, 2022

Ok, so the bug isn’t visible in the Svelte REPL for obvious reasons, but I think I have a basic understanding of why it’s happening:

On line 32, in the l (cLaim) method, the children of the <main> are being detached. The HTML isn’t put back until line 42 in the m (Mount) method. Between claim and mount, the addition of the resize listener is somehow causing Chrome to reset the scroll (presumably Firefox waits until work is complete before assessing whether it needs to). I’m not sure why innerHTML = html doesn’t happen during claim. Will raise an issue on the Svelte repo.

So we have lots of fixes to choose from:

move the banner with the bind:clientHeight to below the HTML block
reimplement it so it doesn’t need bind:clientHeight
add resize observer bindings to Svelte so it doesn’t need to use the resize listener hack
populate {@html ...} tags during claim instead of mount

Rich-Harris on Mar 4, 2022

Can not reproduce the behavior when default-clicking a link from another page (external or internal), i.e. the links in the Github comments above.

However, when middle-mouse-clicking, ctrl-clicking, or pasting the URL into a new tab, the scroll offset doesn’t apply just as described in the issue. The same happens when I modify a link in this issue by adding target="_blank".

I’m not sure if that’s supposed to work like that, due to some browser limitations or something, so I’m not sure that helps.

Version 1.37.111 Chromium: 100.0.4896.79 (Official Build) (64-bit)

psytrx on Apr 14, 2022