Incorrect secondary nav item is displayed as active despite correct URL hash

[jrinehart-buf]

Context

No response

Bug description

On a vertically "tall" display, if a user navigates to the last item in the secondary navigation and the item's content doesn't occupy enough space to scroll past prior sections, the secondary navigation displays the prior section as "active." The URL contains the correct hash, which leads me to think that it could be used to resolve the user's intent, despite the scroll position of the page.

Related links

Documentation reviewed:

• https://squidfunk.github.io/mkdocs-material/setup/setting-up-navigation/

Possibly related issues:

• Rightbar toc-item active link is not working #1738
• Scroll active navigation/toc item into view #1567

Issue search used:

• I have skimmed the titles of all search results for closed issues with "active" and "navigation"

Reproduction

This can be reproduced on a page on the mkdocs material site: no ZIP necessary.

Steps to reproduce

1. Open a browser window with a 1440x1000 size.
2. Navigate to the Ensuring data privacy page.
3. Click "Custom Cookies" in the secondary navigation.

I would expect "Custom Cookies" to be displayed as active because the URL hash ends in #custom-cookies, but "Advanced Settings" is displayed as active.

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 using the built-in info plugin.

[squidfunk]

Thanks for reporting. The active item in the table of contents is deduced from the scroll offset, not from the URL fragment. In your screenshot, the browser has not passed the "Customizations" headline, which is why "Advanced Settings" is still highlighted. We could, theoretically use the fragment immediately after navigation to override the active table of contents item and highlight the anchor that was jumped to, but the moment you scroll by 1px, it will change back to "Advanced Settings".

Thus, since those are two different things, it's not fixable.

[nicksnyder]

We could, theoretically use the fragment immediately after navigation to override the active table of contents item and highlight the anchor that was jumped to, but the moment you scroll by 1px, it will change back to "Advanced Settings".

This seems worth doing to me. The current experience of clicking on an item and seeing a different item highlight is jarring and feels broken. If I then scroll and the highlight changes, that is an understandable interaction.

[squidfunk]

This seems worth doing to me. The current experience of clicking on an item and seeing a different item highlight is jarring and feels broken. If I then scroll and the highlight changes, that is an understandable interaction.

@nicksnyder awesome, PR appreciated! ☺️ While it's definitely not the most impactful invest of our time right now, as we're focusing on foundational work, we can consider a PR if we can gravitate towards a solution that address my concerns I raised in #8210 (comment).