-
Notifications
You must be signed in to change notification settings - Fork 436
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Anchor links appear at bottom of page instead of top #400
Comments
Here's a demo (https://github.com/tao/turbo-scroll-bug).
This happens on Firefox. On Chrome, the turbo link behaviour seems to puts the link in the center of both pages. |
Closes hotwired#400 Before finishing a Visit by scrolling to an element, wait for an additional animation frame (with the `nextAnimationFrame()` utility which calls [requestAnimationFrame][] behind the scenes). [requestAnimationFrame]: https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame
Closes hotwired#400 Invoke `Visit.goToSamePageAnchor()` earlier in the `BrowserAdapter.visitStarted()` delegate method. If a `Visit` is to an anchor on the same page, invoke it at the same time a simulated request that's pre-populated from a `VisitResponse` instance in the hopes that the asynchronous Visit delegate callbacks won't be in competition with the same-page scrolling asynchrony.
Closes hotwired#400 Invoke `Visit.goToSamePageAnchor()` earlier in the `BrowserAdapter.visitStarted()` delegate method. If a `Visit` is to an anchor on the same page, invoke it at the same time a simulated request that's pre-populated from a `VisitResponse` instance in the hopes that the asynchronous Visit delegate callbacks won't be in competition with the same-page scrolling asynchrony.
Closes hotwired#400 Before finishing a Visit by scrolling to an element, wait for an additional animation frame (with the `nextAnimationFrame()` utility which calls [requestAnimationFrame][] behind the scenes). [requestAnimationFrame]: https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame
Closes hotwired#400 When processing a `Visit`, invoke `Visit.performScroll()` while loading a response, loading a Snapshot, or executing a same-page anchor navigation. After in-lining those calls to more appropriate points in the Visit lifecycle, this commit removes the `performScroll()` call from the `Visit.render()` method.
Closes hotwired#400 When processing a `Visit`, invoke `Visit.performScroll()` while loading a response, loading a Snapshot, or executing a same-page anchor navigation. After in-lining those calls to more appropriate points in the Visit lifecycle, this commit removes the `performScroll()` call from the `Visit.render()` method.
Thanks, this does seem to solve the example problem that I linked on both Firefox and Chrome... but having trouble with my production site first and I'm not 100% yet what's going on yet or if I'm just making a mistake including the new code. On Chrome it still seems to place the content in the centre. On Firefox, when I update the url manually in the url bar then it loads the page and scrolls down to the correct place each time, but it seems like when I click on a link inside the page and turbo replaces the content then it still loads the anchor link at the bottom of the page. I'm going to try debug it a bit more over the next few days and see if I can figure something out... perhaps it's some javascript code interfering with the page render step. anchor-link-demo.mov |
The initial problem seems to be solved, so I'm happy with that solution. However, another problem does occur, but it doesn't seem related as it happens whether I use the pull request or not, and with or without the snippet. So might be best to open another ticket for this. In this video below, you can see I'm on the top of the page, visit a link and it appears at the top of the view in the correct position... but when I return to the starting page it loads it at the bottom? Perhaps when I visit the anchor link it stores the scroll position which is half way down the page, and when you return to the cached page it doesn't restore the scroll position of the cached page? back-bug.movIt appears to work up to a certain point, so links 1-13 allow you to return to the top of the previous page... but at 14 in this example it goes to the bottom... so maybe after the current page length is greater than the cached page length it puts it at the bottom? Screen.Recording.2021-11-29.at.12.27.24.mov |
Closes hotwired#400 When processing a `Visit`, invoke `Visit.performScroll()` while loading a response, loading a Snapshot, or executing a same-page anchor navigation. After in-lining those calls to more appropriate points in the Visit lifecycle, this commit removes the `performScroll()` call from the `Visit.render()` method.
Was this resolved by #571? |
Closes hotwired#400 When processing a `Visit`, invoke `Visit.performScroll()` while loading a response, loading a Snapshot, or executing a same-page anchor navigation. After in-lining those calls to more appropriate points in the Visit lifecycle, this commit removes the `performScroll()` call from the `Visit.render()` method.
Closes hotwired#400 When processing a `Visit`, invoke `Visit.performScroll()` while loading a response, loading a Snapshot, or executing a same-page anchor navigation. After in-lining those calls to more appropriate points in the Visit lifecycle, this commit removes the `performScroll()` call from the `Visit.render()` method.
Closes hotwired#400 When processing a `Visit`, invoke `Visit.performScroll()` while loading a response, loading a Snapshot, or executing a same-page anchor navigation. After in-lining those calls to more appropriate points in the Visit lifecycle, this commit removes the `performScroll()` call from the `Visit.render()` method.
@tao I've rebased #476, could you verify whether or not it still fixes the behavior like you mentioned in #400 (comment)? |
@seanpdoyle I tried again with #476 and If I disable With smooth scroll enabled it still does lots of strange things on different browsers, especially on Firefox it's giving me strange behaviour. Chrome seems like it works with the smooth scrolling enabled much better but loads anchor links in the middle of the page. But if I include this script again #426 just after I include the turbo script then it seems to all work correctly without any issues and smooth scrolling enabled.
So it's all looking good, I'm going to continue testing it tomorrow and see if I can finally include turbo on my site. |
Closes hotwired#400 When processing a `Visit`, invoke `Visit.performScroll()` while loading a response, loading a Snapshot, or executing a same-page anchor navigation. After in-lining those calls to more appropriate points in the Visit lifecycle, this commit removes the `performScroll()` call from the `Visit.render()` method.
* Perform scrolling prior to Visit completion Closes #400 When processing a `Visit`, invoke `Visit.performScroll()` while loading a response, loading a Snapshot, or executing a same-page anchor navigation. After in-lining those calls to more appropriate points in the Visit lifecycle, this commit removes the `performScroll()` call from the `Visit.render()` method. * Fix flaky Form Submission Test Resolves a [flaky test][] by replacing a call to `nextBeat()` with a helper that will wait until the target element (in this case, `turbo-frame#frame`) dispatches a particular event (in this case, `turbo:frame-load`). [flaky test]: https://github.com/hotwired/turbo/runs/7570036350?check_suite_focus=true#step:12:16
I found that on Firefox / Firefox mobile / Chrome that when I use an anchor link, sometimes it loads it at the bottom of the page instead of the top.
I believe I've narrowed this down to the following css:
If I remove this scroll-behavior then the issue disappears but my app requires smooth scroll so I don't disorientate the user when jumping between paragraphs.
My pages are long articles with anchors for each paragraph and they are numbered starting at anchor#1 up to anchor#40 for example.
If I am at anchor#3 and click on a higher number like anchor#15 it'll scroll down and put that anchor at the bottom of the page... so it must be scrolling until the anchor is in-screen but not to the top of the viewport.
If I am at anchor anchor#35 for example, and click a lower number like anchor#4 then it looks like it scrolls up the page and puts the anchor at the top of the page because it's higher up. This must be because the anchor only appears into view at the top of the page and then it stops. This bug happens when you load new pages, but not when jumping between paragraphs on the same page.
So I only found the problem going from lower numbers like anchor#3 to a higher one like anchor#15 where the next link has a much higher
Y
position on the new page. As soon as the anchor appears at the bottom of the page it must stop the scroll calculation and leave the anchor at the bottom instead of the top of viewport.The text was updated successfully, but these errors were encountered: