doc: hash navigation seems broken

[vsemozhetbyt]

📗 API Reference Docs Problem

• Version: 16.6.2
• Platform: Windows 10 x64

Location

Many API sections

Description

If you open an API page and then go to some hash part of the same page in the same tab, it seems OK:

current.gif

If you open an API page and then click on some hash link to open it in a new tab, the page in the new tab shifts (scrolls) further after a while by a significant amount (delayed loading of some dynamic content may be the culprit):

new.gif

Tested with the last Google Chrome version (95.0.4608.0).

[Trott]

Confirmed. That's strange. @nodejs/website

[lpinca]

I can reproduce on Chrome 92 but not on Firefox 91. It work as expected there.

Edit: Microsoft Edge 92 also works fine so I suspect it is a Chrome issue.

[Ayase-252]

Tested on Safari, it also works as expected. 🤔

[vsemozhetbyt]

Posted as Chromium issue to be on the safe side: https://bugs.chromium.org/p/chromium/issues/detail?id=1240147

[KuthorX]

Chrome version 117.0.5938.92 on Windows10 can be reproduced.
But I use ctrl+shift+R reload page, it will scroll to wrong position, and the probability of occurrence is 50%.
The gif can be found at here

[valadaptive]

I can reproduce this problem on Firefox. Clicking on a link in the ToC will very often send me to a completely different part of the page:

Peek.2024-06-28.19-50.mp4

I don't believe this is a browser issue.

[valadaptive]

I posted this in #53584, but posting it here as well.

This is not a Chromium bug, and occurs in Firefox as well. I believe it was not previously showing up in Firefox simply because they had not yet implemented the relevant CSS feature.

This appears to be an effect of #37301. Lazy-loading the content means it is impossible for the browser to tell where to jump to, because it hasn't done the layout. And it hasn't done the layout because we explicitly told it not to. This is not a bug, this is the feature working as intended.

Optimizing for the case of reading the entire API docs on a single huge page, at the expense of making it frustrating and difficult to navigate the individual documentation sections that show up way more often in web search results, seems like the wrong decision to me.

[RedYetiDev]

If you find the culprit, feel free to submit a patch :-)

[valadaptive]

The fix would be reverting #37301. Would that be acceptable?

[RedYetiDev]

You can try, whether or not it lands is a discussion for the PR, not this issue.

[valadaptive]

Ah, looks like it was already attempted in #41869. Apparently removing the hack causes some breakage, although no screenshots were provided. Currently trying to figure out how to build the documentation...

[valadaptive]

OK, just tracked it down and it was fixed in #53510 already which hasn't landed yet

[RedYetiDev]

OK, just tracked it down and it was fixed in #53510 already which hasn't landed yet

That PR has landed