Forcing tabindex to -1 on a scrollbar viewport container allows it to become an active element

[siarhei-epam]

Describe the bug
When using OverlayScrollbars, the library forcibly adds tabindex="-1" to the scrollbar viewport element. As a result, clicking any empty (non-interactive) area inside the content wrapped by OverlayScrollbars changes focus unexpectedly: document.activeElement becomes the viewport instead of the default document.body. This breaks logic that relies on the browser’s default focus behavior (e.g., global keyboard shortcuts, blur handlers, focus traps).

To Reproduce
Steps to reproduce the behavior:

1. Initialize OverlayScrollbars on a container with mostly non-focusable content.
2. Ensure no inner control is focused (focus is on body or a control outside the scrollable area).
3. Click on an empty spot inside the scrollable content (not on links/inputs).
4. Observe in console that document.activeElement switches to the OverlayScrollbars viewport (the element with tabindex="-1"), instead of staying on body.

Expected behavior
Clicking on non-interactive, empty space inside the scrollable content should not change active element. The default behavior should be preserved: document.activeElement should remain document.body (or the previously focused element). OverlayScrollbars should avoid stealing focus implicitly—e.g., by not applying a tabindex that causes viewport active on click, or by ensuring clicks on empty areas do not move active element to the viewport.

Examples
Observe in console:

• React: https://stackblitz.com/edit/vitejs-vite-9xtgl8id?file=src%2FApp.jsx

Environment

• OverlayScrollbars version: "overlayscrollbars": "2.12.0", "overlayscrollbars-react": "0.5.6"
• Used Operating System(s): win11
• Used Browser(s) (with version): 140.0.7339.128 (Official Build) (64-bit)

Additional context
Focus management APIs
MDN

[KingSora]

Good day @siarhei-epam :)

This behavior was implemented to improve accessibility for keyboard users. Native scroll-containers will receive automatic keyboard focus if they or their scrollbars are clicked / interacted with. The problem there was that Firefox and Chrome (and probably also Safari) had different behaviors when it came to focusing scrollable containers. In Firefox you could call container.focus() on the scrollable container and the container would always receive focus regardless of its tabIndex. In Chrome this was different until v130, the container had to have a tabIndex in order to make the focus() call have any effect. Recently chrome changed that behavior here is the blog post.

So I'm a bit torn here.. On the one hand I think that the keyboard accessibility is really important here (especially when interacting with the scrollbars) but at the same time I understand your usecase. Maybe you have a good idea how to solve both problems at the same time.

That being said, you can use a plugin as a workaround: https://stackblitz.com/edit/overlayscrollbars-dkjgbdm2?file=src%2FtabindexPlugin.ts,src%2Findex.ts

The osTabIndexPlugin in the sandbox example above will remove the tabIndex attribute from the viewport element of any instance.

[siarhei-epam]

Good day @KingSora :)

I suggest adding an option to the component API that allows enabling or disabling the automatic addition of tabindex="-1", with the default behavior disabling it entirely. This would help scrollbars remain consistent with the browser's native behavior. While the current implementation was introduced to address browser inconsistencies, this was never a problem caused by the library itself, and altering the default behavior in such cases may not be ideal. Now that modern browsers, like the latest versions of Chrome, have resolved this issue, it might make sense to revisit this approach for better alignment with standard browser functionality.