Closed Rich-Harris closed 2 years ago
Testing fix now
You're never going to believe it, but it was introduced in #4155 somehow.
Makes sense, because it scrolls to the correct position temporary and then returns to 0
It's probably something to do with that clientHeight/Width bind, some Chrome edge-case/bug, but no idea how to fix it, maybe there is some other way to do that banner without that bind
Most of the more complicated stuff with the banner is no longer necessary with the shorter message on mobile that doesn't need to wrap. The whole thing should be able to be replaced with an HTML- and CSS-only banner that swaps out messages with media queries.
I think I actually figured the root cause of the issue
Closed #4219 it was just hiding the issue, need to investigate deeper.
Before this block of code, the page is correctly scrolled: https://github.com/sveltejs/kit/blob/cdc32a9f4f17d69be6ca1cae58bf3961155545a2/packages/kit/src/runtime/client/client.js#L330-L334
After, it's reset. So it's something to do with the hydration. Trying to create a minimal repro.
I think the browser tries to scroll, but the max scroll(full page height) changes slightly when hydrated(maybe just 1 pixel) and that causes it, but how to solve it is beyond me.
Ok I've managed to at least make a simpler repro: https://stackblitz.com/edit/sveltejs-kit-template-default-pm2sdq?file=src%2Froutes%2Ffails.svelte&terminal=dev
Visit https://sveltejs-kit-template-default-pm2sdq--3000.local.webcontainer.io/ and try going to works
and fails
. There's something about the combination of {@html ...}
and bind:clientHeight
that causes the scroll to be reset on hydration.
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 😊
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:
bind:clientHeight
to below the HTML blockbind:clientHeight
{@html ...}
tags during claim instead of mount@Rich-Harris I'm on my phone now, but one solution I can think of is to save scroll position(inside client.js) to const before calling new Root and after it just do scrollTo(pos.x, pos.y)
I don't it's good to just fix it for the docs site because that bug could be happening on some other sites we don't know about. That's just one of the most simplest solutions but your solutions are definitely better.
@Rich-Harris It's happening again for me on the docs site, for ex. link https://kit.svelte.dev/docs/routing#advanced-routing-fallthrough-routes you posted in https://github.com/sveltejs/kit/issues/4291#issue-1165916525 Interestingly enough, it happens most of the loads, but not always.
Interestingly enough, it happens most of the loads, but not always.
Same here! Crazy! 😄
@Rich-Harris any idea why this could be happening? because I have none, one workaround I can think of is to check if hash is present and scrollTop is 0, If both are true then we do document.getElementById(location.hash.slice(1)).scrollIntoView()
or something like that in client.js
but I understand it's bad design.
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
It is working fine for me...
Version 1.37.109 Chromium: 100.0.4896.60 (Official Build) (64-bit)
Didn't work for me(Will attach the right version tomorrow)
Works for me using Chrome Version 100.0.4896.75 (Official Build) (x86_64)
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)
Used to be broken in Safari as well. But seems to work from version 324
Faced this bug while I was learning sveltekit.
Click on this link Generated Types
, it doesnt scroll to that position on Chrome. But sometimes it does, very finicky.
I might have happened on a related issue - I'm finding that Chrome 102.0.5005.63 doesn't scroll to hash when the page is doing an inertial scroll from scrolling with a mouse. Hash links work only when the page has completely stopped moving from inertial scrolling.
Scrolling when inertial movement is in effect seems to be working on SvelteKit docs site though.
Can't reproduce this anymore, therefore closing this. The PR that would fix the underlying issue is https://github.com/sveltejs/svelte/pull/7426
Please reopen, middleclicking the link does not scroll to the hash in recent chromium based browsers.
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
Severity
annoyance
Additional Information
No response