Repeated click on anchor link fails to jump to target when navigation.instant is enabled

[sisp]

Context

No response

Bug description

When the navigation.instant feature is enabled, clicking on an anchor link (e.g. a ToC link), then scrolling elsewhere, and then clicking on the same anchor link again does not work; the second click on the same anchor link does not jump to its target anymore. Clicking on another anchor link works fine though. The problem does not occur when navigation.instant is disabled.

Related links

• Reporting a bug
• Setting up navigation – Instant loading

Reproduction

9.2.7-xhr-anchor-links.zip

Steps to reproduce

1. Open the minimal reproduction site in the browser.
2. Click on a ToC link, e.g. "Lacrimas debentia", such that the browsers scrolls down to that section.
3. Scroll elsewhere.
4. Click on the same ToC link again and observe that the browser does not scroll to that section.

Browser

No response

Before submitting

• I have read and followed the bug reporting guidelines.
• I have attached links to the documentation, and possibly related issues and discussions.
• I assure that I have removed all customizations before submitting this bug report.
• I have attached a .zip file with a minimal reproduction.

[squidfunk]

Fixed in 7e6f15b. Sorry it took so long, but this was quite tricky! Took me 3 attempts.

Problem

The problem is that clicks on anchor links emit on location$, which triggers the entire observable chain. This is also why when intercepting clicks on anchor links, we must filter emissions with the same hash as before, leading to the reported problem – repeated clicks do nothing. We must jump through a lot of hoops to get instant loading right, because so many things can happen in the browser, and we must disable scroll restoration and manage scroll position manually, or going back and forth will not work correctly, mainly because the browser will already try to scroll into the position before the page has actually loaded. The instant loading code is heavily documented (after I did the last refactoring, which made it much more stable), so if somebody wants to learn how it works, reading the code is definitely a good idea.

Solution

We create a second observable chain that intercepts emissions on location$ that deliberately go to the same anchor link, but sample it with instant$, which limits emissions to explicit navigation. Then, we navigate to the hash, which will add an entry to the history, which we then remove again. This positions the browser back at the anchor link, but doesn't fill up the history with the same anchor link over and over again.

This commit fixes another problem where tracking of scroll offset was not recorded before the first navigation. We track the offset and store it in the latest history state entry, so that when you go back, you land at exactly the same scroll position, even though you might go to an anchor link. This logic was only mounted after the first instant load, so if you clicked anchor links before navigating, the position was not recorded.

My testing shows that the problem is solved. Can you confirm?

[vedranmiletic]

@squidfunk Just saw this fix in git log, kudos for it. Students tend to click quite fast, and network in the classroom can be a bit laggy with two dozen computers using it at the same time. Taking that into account, this issue used to occur more often than anyone would like and I am glad it is finally addressed. I am sure the students will appreciate it as well.

[squidfunk]

It's really awesome to read that my work is being used in universities. When I was a student myself, I would've loved to learn about a technology like this in class. Kudos for using my work for teaching 🚀

[squidfunk]

Released as part of 9.4.2.

[sisp]

Sorry for my delayed response, @squidfunk.

Sorry it took so long, but this was quite tricky! Took me 3 attempts.

No worries, I had no expectations on timeline. It didn't feel like an obvious problem, so I appreciate your efforts in finding a proper fix! 🙏 Also, thank you very much for the detailed analysis and solution report! It indeed looks like a tricky problem to solve.

My testing shows that the problem is solved. Can you confirm?

I confirm it's working now! Thank you very much! 🙇