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.
Can you made a quick video of exactly the issue you see. I don’t see Chrome (nor Firefox) scrolling all the way down.
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?
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.
Following because I am having the same issue with the TOC scrolling to the wrong location (2nd click does the trick). Like OP, I’m also seeing inconsistencies with the active styles - where the item I click does not become active. Rather an item further down the page gets marked as active.
Disabling a CSS based smooth-scroll did fix my issues around scrolling to the incorrect place. I also tested by enabling the Bricks smooth-scroll setting in Bricks Settings > General and that continued to work well. However, I’m still seeing issues with the wrong item being marked as ‘active’.
what is the structure of your content? I tried to replicate it, but I could not. Although, I remember that I’ve already read somewhere about the similar thing, so probably I just can’t replicate it with my setup.
Hi Matej, thank you for the reply! Here’s a link to the page with the issue. I have Bricks’ smooth scrolling (from settings) enabled and am using the Bricks TOC component to target H1 and H2s (except those that are inside a .cta card or an eyebrow element)
All of the content is built on Bricks. While it seems the scrolling is no longer offsetting incorrectly, I am still seeing the following issues with the TOC:
The active item is not correct - it seems the TOC is marking headings that are way below the active content.
I have this toc set to ‘collapse inactive’ but any H2’s that are under the first H1 (part 1: A Peek inside…) do not show up. Additionally, because of the incorrect active location, you often see the incorrect heading collapsed, making navigation confusing.
thank you for the link. I can easily replicate the issue there. Can you send temporary login credentials to your website and a link to this topic to help@bricksbuilder.io using the email address you used during the purchase, so I can copy-paste the sections, and try to reproduce the same ones in my local install?
Thanks Matej, I can send those. However, the email address used during the purchase belongs to an old boss - I have access to the account, but not the email address and it may take a couple of days to get that changed. If we can move forward with my own email, I can have that information over asap.
in this case, you can still send the email - just please explain the situation, so that if anyone else opens it, it will know and include the old email and license key or a screenshot of a my.bricksbuilder dashboard with license key/email, so we can verify it
thank you for the login access. I checked your website, and it might be the same issue as it was reported here:
It seems that “position:relative” is the reason for this, even in your case. But to confirm that, can you test this on your staging website, by removing the position:relative from your elements?
I think .section-title-card and .guide-section does have a position relative. I set it to static, and the issue, as far as I see, should be solved.
Can you confirm it? If not, I’ll check further - just let me know where you clicked and that it was not working
Hey everybody - Matej is a rockstar!
This was most definitely the issue, thank you Matej! After removing all position:relative properties from my content section, the table of contents scrolls accurately and marks the correct TOC item as active.
Now my goal will be to simplify my content to work with this structure - simple is better here. Cheers!
I’m glad to hear that removing position:relative worked . We do have an improvement task for this locally, and we will update the other topic, once we implement the fix/improvement:
For that reason, I’ll close this topic, and mark it as duplicate - just so that we have everything in one place.
.
. We do have an improvement task for this locally, and we will update the other topic, once we implement the fix/improvement: