WAIT: "Smooth scroll (CSS)" setting enabled causing inconsistent scrolling with Tabs (nestable) and Table of contents elements

Browser: Firefox 138.0.1 and Chrome 136
OS: Windows (10) for sure (macOS, tentatively). Likely across all platforms

I’ve noticed very odd scrolling behavior with both the Tabs (nestable) when using direct links to the tabs, as well as the Table of contents element. I have a sticky top nav bar. The footer is pushed to the bottom so that there is always a scrollbar and no layout shifts if the page doesn’t have enough content, vertically. The navigation and scrolling behavior seems different depending upon whether I’m using Chrome or Firefox. I haven’t been able to fully narrow down the source—if this is a Bricks bug or a user error situation.

URL: Downloads - Dataclay
For Tabs (nestable), direct links (like above) are scrolling the page unnecessarily. Disabling smooth scrolling resolves the issue in Firefox, but Chrome scrolls all the way to the bottom of the page. I don’t know if this is some sort of calculation conflict with elements that have height and/or min-height? The tabs “bar” is also sticky.

URL: Terms Of Service
For Table of contents, clicking on the links for headings that are further down the page will scroll those headings to the middle of the browser, and a second click will scroll them correctly to their Headings offset position. Clicking on links for headings above the current position correctly scroll (most of the time).

On Firefox, if I disable smooth scroll, the Heading offset is ignored. I believe that’s a known bug.

Hey @blakmarkitcreative,

I’ve tested and checked both of your reports:

  1. Can you made a quick video of exactly the issue you see. I don’t see Chrome (nor Firefox) scrolling all the way down.

  2. Yep, this might be related to the one issue we noticed with the Firefox, where it does not correctly calculate the “offset”. If you remove the “offset”, do you still see the issue?

Matej

I’ll try to record a video later this afternoon. The scrolling all the way down on Chrome is only seeming to happen if I have smooth scrolling disabled (it’s enabled at the moment).

For the ToC issue, the click once then twice issue to scroll to the correct heading seems to only happen if smooth scrolling is enabled, but it was happening on both browsers. The offset was seemingly only being ignored in Firefox if smooth scrolling was disabled.

This may or may not be related, but I noticed that in some cases if I clicked on a heading, the “active” heading will often be different than the one I clicked on, seemingly based on its viewport position. From a UX perspective, that is confusing—it’s perhaps less confusing when it changes as you scroll, to give you a sense of the overall position in the document, but it’s not great when the active/highlighted heading is not the one you just clicked on. Is there a way to control this behavior? It seems like the tocbot library settings that would be necessary aren’t exposed in the element’s settings.