Page does not scroll to anchor once loaded in local dev env

[queengooborg]

Summary

While testing #7129, I happened to notice that the page did not scroll to the specified anchor in the hash once it has loaded. I believe this is because we are solely relying on the browser to navigate us to the right anchor, but since the page performs additional loading with React components, the target element isn't loaded by the time the browser wants to scroll to it. We'll need to implement our own code to scroll to the target element after loading.

URL

https://localhost:3000/en-US/docs/Web/HTML/Element/button#attr-autocomplete

Reproduction steps

Simply open the above link, or any link that has a hash.

Expected behavior

The browser should scroll down to the specified element -- in the above URL's case, the autocomplete attribute description.

Actual behavior

The browser stays at the top of the page.

Device

Laptop

Browser

Chrome

Browser version

Stable

Operating system

Mac OS

Screenshot

No response

Anything else?

No response

Validations

• [X] I have read the Community Participation Guidelines.
• [X] I have verified that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• [X] I have checked that this is a concrete bug. For Q&A open a GitHub Discussion.

[caugner]

@queengooborg Could it be that you experienced this issue locally? If you visit https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button#attr-autocomplete directly, you're getting a SSR version and you should get to the right section, but if you're working locally, the page is client-side rendered and afaik React-Router doesn't handle hash navigation natively, and our attempts to fix this have so-far failed.

If you find a solution, that would be awesome. But note that just reading the hash and navigating the on load does not seem to be the solution, because when you use the Forward/Backward button in your browser you expect to get to the last scroll position you were at, which is not necessarily the position of the hash. 😕

[queengooborg]

Ack -- yes, I'm only experiencing this in the dev runtime, my bad!

I'll see what I can do to resolve this!

[caugner]

Hm, but maybe this is an issue even with prod build, see: https://github.com/mdn/yari/issues/7168

(Never mind, can no longer reproduce that issue.)

[tlylt]

But note that just reading the hash and navigating the on load does not seem to be the solution, because when you use the Forward/Backward button in your browser you expect to get to the last scroll position you were at, which is not necessarily the position of the hash. 😕

Hi there, could you clarify the procedure to reproduce the problem when using Forward/Backward button? It seems like browsers might be smart enough to handle the case accordingly.

I'm experimenting with VuePress Docs (not sure what they do for anchor scrolling, but I'm just testing):

• I am on this page with URL including the hash https://vuepress.vuejs.org/guide/directory-structure.html#default-page-routing
• I scroll back up to the top such that the URL is still the same but I am actually at a place not matching the hash
• I click on "getting started" on the sidebar to go to another page
• I click backward on browser
• the URL still contains #default-page-routing but the page shows the top instead
• Clicking forward and backward again on the browser shows the same correct result (page is at the location of my previous visit, not at the hash)

Perhaps when navigating forward and backward, the browser events are slightly different and it could happen that a navigating on-load won't cause any problem?

[Josh-Cena]

Duplicate of #5733

[tlylt]

Had some similar issues somewhere else and the resolution is to tweak the timing of calling the function that scrolls the page to the anchor. Perhaps because the page is not fully loaded when the scrolling is done, the scroll does not work at all as it cannot find the anchor element. Might be relevant here.

[taymonbeal]

This is consistently happening to me in production, but only on some pages. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/TypedArray/findLast#specifications, https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/fromEntries#browser_compatibility, and https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/TypedArray/indexOf#browser_compatibility trigger the bug, but https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer#browser_compatibility and https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/formatToParts#browser_compatibility do not.