Not getting correct element when searching for scroll parent element in effect?

[ryanzec]

Describe the bug
When I attempt to programmatically get the scroll parent for an element inside an overlayscollbars element, I get the initializer element instead of the content elemnt which is the real scrollable element.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://stackblitz.com/edit/overlayscrollbars-solid-dr7ccyvu?file=package.json,src%2FApp.tsx
2. Scroll the scrollable area and check the console logs

Expected behavior
I would expect the 1 to be logged out however I get 2 so it seems like the instead of getting the scroll parents element, it is getting the element one level higher. I also tried doing it manually instead of use scrollparent and got the same issue.

Examples
https://stackblitz.com/edit/overlayscrollbars-solid-dr7ccyvu?file=package.json,src%2FApp.tsx

Environment

• OverlayScrollbars version: 2.11.1 (overlayscrollbars-solid: 0.5.6)
• Used Operating System(s): Mac 15.3.1
• Used Browser(s) (with version):Chrome (137.0.7151.120)

[KingSora]

Good day @ryanzec :)

I'll take a look as soon as I have time - this seems to be caused by wrong timings / assumptions about when effects run.

[KingSora]

@ryanzec Alrighty, so:

• The effects of children components run before their parents effects.
• Since the OverlayScrollbarsComponent is using an effect to initialize, the effect of AnotherComponent will always run before that, since its an child of OverlayScrollbarsComponent.

Essentially, the effect where the scroll parent is determined is not taking into account all of its dependencies, thats why it might be wrong. Its "real" dependencies would be all parent elements (since a change in the DOM structure could mean a differen scroll parent), but that might be hard to track, so lets define a more sane set of dependencies. Lets say the scroll parent is only dependent on OverlayScrollbars and whether it is "ready".

This can be achieved with the events prop on the OverlayScrollbarsComponent:

<OverlayScrollbarsComponent
  events={{
    updated: () => {
      setOverlayScrollbarsIsReady(true);
    },
  }}
/>

Notice that I'm using the updated event and not the initialized event, since the initialized event is fired after the DOM element are initialized (e.g. placed at the correct place in the DOM) but they might not have the correct styles. Those are set after the first updated event, so thats why the signal is set there.

Not this state has to be propagated to the place where the scrollparent is determined and used in its effect. You can either pass the state as a prop or use a context for that.

createEffect(() => {
  overlayScrollbarsIsReady(); // so the effect re-runs after the signal changed

  const elm = element();
  const scrollParent = getScrollParent(elm);

  // scrollParent should be correct now
});

Here is a demo with the code: https://stackblitz.com/edit/overlayscrollbars-solid-dr7ccyvu?file=src%2FApp.tsx

I've also added a background color change to the scroll parent element, so you can see when it changes.

[ryanzec]

@KingSora Did you mean to link my original example of a different one?

[ryanzec]

So then since the child component can't know upfront if it is in a overlayscrollbars component, the best solution would be to have my wrapper that handles the overlayscrollbars component to have a provider and then anywhere I need to get a scrollable parent, I attempt to get the overlayscrollbars wrapper context. then in the effect I can just do a check like:

if (scrollAreaContext && scrollAreaContext.isReady() === false) {
  return;
}

// scrollable parent element work

This should mean that the scrollable parent element work is only done if the element is not in my overlayscrollbars wrapper or the wrapper is ready.

[KingSora]

@ryanzec Sorry, must've copied the false link.. here is the example: https://stackblitz.com/edit/overlayscrollbars-solid-vuc5yavs?file=src%2FApp.tsx

[ryanzec]

So your solutions does work but only if the overlapscrollbars component is scrollbar when ready, if it is not, the standard pattern for getting the scroll parent still returns the <html /> element. This is a problem as I need to be able to attach a scroll event to the element that will be scrolling which in not the <html .>, it is the overlayscrollbars element (though when there is not enough content, it is not known that it will be the scrolling element).

What I have done is created this method:

const getScrollParent = (element: HTMLElement, inOverlayScrollbars = false): HTMLElement | null => {
  if (inOverlayScrollbars === false) {
    return scrollParent(element);
  }

  return element.closest('[data-overlayscrollbars-contents]');
};

Then when I call this, I do:

domUtils.getScrollParent(currentScrollElement, scrollAreaContext !== undefined);

This way, if we are in a scroll area (which is known if there is a scroll area context that is available), I just explicitly get the closest element with data-overlayscrollbars-contents (the scrollbar element from overlayscrollbars from my understanding).

While this seems to work, I want to confer with you that given my use case, would this be the best way to handle make sure I am getting the correct element up front even if there is initially not enough content to trigger a scroll.

[KingSora]

@ryanzec I would do something like this:

const getScrollParent = (element: HTMLElement, osInstance?: OverlayScrollbars): HTMLElement | null => {
  const scrollparent = scrollParent(element);
  if (!osInstance) {
    return scrollparent;
  }

  const { viewport } = osInstance.elements();
 
  // in case you have a nested scrollable element
  if (viewport.contains(scrollparent)) {
    return scrollparent;
  }

  return viewport;
};

[KingSora]

@ryanzec would you consider this issue as solved or is anything still open? :)