Incorrect positioning of clickable area for navigation links in Safari/macOS about just-the-docs HOT 6 OPEN

Is the issue due to the definition of the scrollNav() function?

When JS is disabled, the position of the clickable area appears to be correct in Safari/macOS:

from just-the-docs.

Thanks for submitting an issue! I actually am unable to reproduce this locally, but I might be missing some information. Could you let me know the size of your viewport? I'm also on macOS Ventura with the latest stable Safari, etc.

from just-the-docs.

It's easiest to see the effect when the viewport width is 840 or 980. On my 13" laptop, that's zoom levels 4 and 3, I think.

It's necessary to avoid manually scrolling the nav panel at all after clicking on the Configuration link: scrolling a bit then back again appears to correct the placement (which is why I suspect our automatic scrollNav() causing the issue when the nav panel is already at the top).

And to repeat the issue, one needs to select a different page first (since the Configuration anchor is inactive after selecting it).

from just-the-docs.

I suspect our automatic scrollNav() causing the issue when the nav panel is already at the top

And after commenting-out the call of scrollNav() locally, the reported issue disappears.

Perhaps the call to scrollBy should be skipped when the nav panel can't be scrolled any further?

from just-the-docs.

Oh! Thank you for reminding me of not scrolling - I must have done that inadvertently (or perhaps it was that and a combination of the viewport on my monitor). I can confirm at zoom levels 3/4, with the viewport range you provided, that the clickable area is incorrect.

I can do some more investigating as well - the scrollNav() hint is helpful. I wonder if there is some undefined behaviour that we're relying on, a known webkit bug with rendering, or something else. For American Thanksgiving I'll be dedicating some time to JtD, so expect an update then!

from just-the-docs.

Okay, I've done a bit more investigation. Just to sum up some interesting notes:

• as expected, the bounding rect itself (from .getBoundingClientRect()) is identical on Safari, Firefox, and Chrome when zoomed in (or not)
• after fiddling around with the values/offsets (e.g. the height multiplier, fixing it to a constant), this problem still persists on Safari
• after doing a (minimal) google search, variants of this bug (zoom + scrollBy not working as intended) have appeared before, such as webkit #45228 - though it doesn't seem like there are any relevant open bugs on the webkit bug tracker (see: "scrollTo zoom" and "scrollByZoom")

Separately, I also realized that the scrollIntoView function has stabilized (see: caniuse), which makes me feel a bit old (I distinctly remember reading the Chrome changelog with the release). Using that instead:

1. fixes the bug
2. makes the logic for the overall method simpler

I'll open a PR to demonstrate!

from just-the-docs.