I have a page which defines some DOM elements with fragment ids:
<h2 id="foo">...</h2>
And I have some anchors on the page that reference these id's:
<a href="#foo">...</a>
This works fine.
What doesn't work is visiting http://.../page#foo - i expect the browser to render the page and then scroll the viewport to the h2 element in the DOM, but it doesn't. I checked the standard in case i was doing something subtly wrong, but according to https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-to-fragid my expectation is correct.
How can i debug this behaviour in Chrome? Specifically, how can i catalogue what the browser is doing after page load with respect to parsing the fragment id in the DOM and handling the fragment id from the URL?
The page is generated in a https://www.docusaurus.io/ site - this generates a static html page and i've verified:
- the static html page is served with a text/html mime type by my server
- the static html contains the id attribute on the dom element
- querying
window.location.hashin the browser console correctly returns the fragment from the URL
Docusaurus does add some JS to the page which runs after loading the static html page and it's performing interception of anchor tags on the page to cause them to render react-router driven "pages" rather than request a full page refresh on click.
I suspect my issue is in this part of the code but i'd really like to understand how chrome is handling my fragment id's.
In the meantime i worked around this by writing a little react component that checks for location.hash and if present, gets the dom element by id and invokes a scroll-to, it surprises me that this works yet the native behaviour doesn't.
