Option prop to control whether the component sets focus on initialization

[Eric24]

Is your feature request related to a problem? Please describe. It appears that the component always sets focus when it is initialized. There are times when this is undesirable, as the focus is set to the OverlayScrollbar (or maybe its parent--in our case, the OverlayScrollbar is inside an iFrame).

Describe the solution you'd like The stated purpose of the focus call is to enable keyboard scrolling without first having to click the page. That's fine in cases where this is important, but it can also cause unintended side-effects. So I'm looking for an option prop to control whether the component makes the focus call or not (something like setFocus: true|false). I don't think there is any other way, as the knowledge of whether or not the focus call is desirable or not can only be known by the developer based on the use-case. For backward compatibility, the default value of this new prop should be "true".

The code that does this is here:

                        //set the focus on the viewport element so you dont have to click on the page to use keyboard keys (up / down / space) for scrolling
                        if (document.activeElement == targetElement && _viewportElementNative.focus) {
                            //set a tabindex to make the viewportElement focusable
                            _viewportElement.attr(LEXICON.ti, '-1');
                            _viewportElementNative.focus();

                            /* the tabindex has to be removed due to;
                             * If you set the tabindex attribute on an <div>, then its child content cannot be scrolled with the arrow keys unless you set tabindex on the content, too
                             * https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/tabindex
                             */
                            setupResponsiveEventListener(_viewportElement, _strMouseTouchDownEvent, bodyMouseTouchDownListener, false, true);
                        }

[KingSora]

Good day @Eric24!

So you're initializing OverlayScrollbars in a iFrame on your page. Are you initializing it from within the iFrame (so the OverlayScrollbars code doesn't know anything outside the iFrame) or are you initializing it from outisde (the main page is accessing the iFrame and then initializing OverlayScrollbars on the body element)?

[Eric24]

Hi Rene! Thanks for the quick reply.

Yes, we have multiple iFrames on the page, and each has its own instance of OverlayScrollbars "inside" the iFrame (it's the content of the iFrame that we are wanting to scroll with OverlayScrollbars), and yes, OverlayScrollbars are not aware of anything other than their "own" iFrame.

[Eric24]

@KingSora - Any feedback on this? Just wanting to know where you stand on it.

[KingSora]

@Eric24 I'm sorry I didn't have time yet to take a deeper look at it.. but generally you shouldn't get a focus on elements after initialization where it wasn't before.. (thats why there is this check: document.activeElement == targetElement)

[Eric24]

@KingSora - No worries, I just wanted to be sure it didn't get lost in the shuffle.

I think the reason I'm seeing the focus is because I'm creating a series of iFrames and "injecting" content into them. Part of that content is the OverlayScrollbars code. I believe that from the perspective of OverlayScrollbars, the full iFrame isn't the activeElement at the time it's initialized.

[KingSora]

@Eric24 ah ok!

So the situation is you have your page, on your page you have the OverlayScrollbars script. Then you're creating some iframes and you're using the OverlayScrollbars script from your original page to initialize OverlayScrollbars inside the iframes. If thats the case its possible for me to disable the focus if the target is inside a different document.

Thats the thing I wanted to know in my first answer, because if you would have had iframes and each frames loads his own OverlayScrollbars script there isn't a way to detect that.

If I think about it, it also makes perfect sense to disable it in a different document, since I've really done this part just for the "original" body element.

[lightsinthesky]

I created a very basic code sandbox that illustrates the issue - https://codesandbox.io/s/loving-oskar-nbdci . On chrome and firefox on osx you can resize the browser frame such that it will scroll and simply update the html to trigger a refresh. The browser frame will scroll all the way to the bottom as the iframes are reloaded. This doesn't happen in safari.

[Eric24]

@KingSora - Any updates on this? The side-effect of always scrolling to the end/bottom happens in non-iframe implementations, too.

[KingSora]

@Eric24 I'm implementing this change for v2 which will release soon :) - The plugin will be smarter about when to set the focus.

[Eric24]

@KingSora - Excellent! I'm glad to hear it. I look forward to testing it out.

[KingSora]

This should be fixed in v2 which released today :)