Please make it so that users of your framework don’t draw their own scrollbars.

[mirabilos]

Describe the bug
Zulip’s web client, which uses your framework according to its developers’ reply to an identical bugreport I submitted there, draws its own scrollbars (probably with JavaScript) when hovering over the browser-provided scrollbars.

To Reproduce
Steps to reproduce the behavior:

1. Configure Firefox suitably so that it always shows scrollbars in a theme close-ish to the system theme for a11y (accessibility) reasons, following the user prefs and user CSS from https://edugit.org/-/snippets/31#note_69290 mostly
2. Run Zulip’s web client
3. Hover over the scrollbar in the bottom-left widget showing a list of users and channels you have a talk with
4. See an extra fake scrollbar, not even aligned correctly, pop up, irritating people (at first I was wondering what it was supposed to be, until I realised it sort of scrolls similar to the real browser scrollbar)

Expected behavior
That, when a browser scrollbar is used (including that when it is preferred by the user) no fake other scrollbar is drawn.

Reproducible example
The JSFiddle template https://jsfiddle.net/Grsmto/57obe5w2/1/ suffices to expose the issue if I move the mouse pointer over the browser-provided scrollbar.

Additional context
Please refer to the aforelinked Zulip issue and the linked page about browser configuration for more accessible scrollbars (I know people who use that as template but make the numbers much larger, for both visual and motoric issues).

Your environment

Software	Version(s)
SimpleBar	whatever Zulip uses
Browser	Firefox ESR
npm/Yarn	no
Operating System	Debian trixie

[mirabilos]

screencast (webm): https://github.com/user-attachments/assets/0401aab8-2181-4ea7-8a38-9d9b0b5475fb

[Grsmto]

Thanks @mirabilos for reporting this. I'm not too sure how to "solve" this but my honest answer is that I don't really see a point of using Simplebar in 2025 (or any other custom scrollbar libraries). I think most browser/OS now support scrollbar customisation and if they don't, well, users know best.
If users use a system that does not support it, they are probably used to/aware/enforced this for some specific reason. But maybe maintainers of Zulip and other projects (Spotify!) have a good reason for using custom scrollbar libraries still today.

That being said, SImplebar is far from being bug-free so this might very well be a bug. Could you check if you see the same issue with the Spotify web app? They are using https://github.com/KingSora/OverlayScrollbars/ (the best scrollbar library out there). I would definitely encourage Zulip to migrate to it since it's well maintained and pretty much bug-free, not like Simplebar. I still see some value in Simplebar as it's "simple", very lightweight, and that's the reason people still use it.

Anyhow I'm still happy to provide a fix if there is an easy way to solve this. Best.

[mirabilos]

my honest answer is that I don't really see a point of using Simplebar in 2025 (or any other custom scrollbar libraries). I think most browser/OS now support scrollbar customisation and if they don't, well, users know best.

I’ll try to tell that the Zulip people. Thanks, that is a surprising response, but then, I’m not a “web developer” (when I do webpages, it’s XHTML/1.1 and basic CSS mostly) so I haven’t followed all this.

If users use a system that does not support it, they are probably used to/aware/enforced this for some specific reason.

Precisely!

Could you check if you see the same issue with the Spotify web app?

I had to research what that is, but https://open.spotify.com/ is almost the same, though more subtle: it’s a slight highlight and very synchronised to the browser scrollbar, so it is only mildly irritating.

I wonder whether it’s possible to find out if a user has disabled browser scrollbar styling and to disable such frameworks then, but I’ll leave that for you and @KingSora for your respective frameworks. Perhaps something with reading out the computed style for scrollbar colour and width from the body element or a dummy subelement where you set a different one? That might work at least with the Firefox way of using userContent.css to enact this user preference. Not sure if any have it in menus… maybe Mobile Safari, it has a whole list of things people can turn on and off under Settings → Advanced → Feature Flags… hah yes, it has scrollbar colour/gutter/width disablable, so another thing to test (which I have no idea how to, I’m a Unix command line, not an Apple, developer).

[KingSora]

@mirabilos Good day :)

If I understand your issue correctly, you've disabled the browsers ability to apply the scrollbar-style related styles and hence you expect simplebar or overlayscrollbars or any library like that to respect those settings and simply do nothing. (Please correct me if I missunderstood)

The first issue I see here is that OverlayScrollabars (but SimpleBar as well) does not interpret the browser inability to style scrollbars as "I should be doing nothing in that case". In OverlayScrollbars case there is even a plugin which overcomes this limitation and manages to still hide the native scrollbars with a different mechanism (its designed as a plugin because modern browsers shouldn't need it, so its up to the developer to decide whether to use it or not, e.g. because the app targets older browsers).

For me the usage of a library like simplebar or overlayscrollbars means that the developer of the web app wants to enforce certain scrollbars styles and the native scrollbars should not be rendered / hidden. The browsers capability of scrollbar styling is just a tool to achieve the libraries goal and not an indicator to "opt out" of the library.

So let me summarize this:

• It up to the webapps developers to decide whether the app renders custom or native scrollbars (they may also have a config for that)
• The browsers inability to style native scrollbars does not mean that a custom scrollbar library should not work (if it is able to overcome this browser quirk)

[mirabilos]

Almost ;-)

It up to the webapps developers to decide whether the app renders custom or native scrollbars

It very much is not. This is an accessibility issue.

[KingSora]

@mirabilos based on your feedback I've now added the following change (with e2e tests) to OverlayScrollbars:

The custom scrollbars will not be rendered if the plugin determines that the native scrollbars can't be hidden. In OverlayScrollbars case this means that the ScrollbarsHidingPlugin is not being used and:

• scrollbar-width css property can't be set to none
• in chromium browsers the ::-webkit-scrollbar pseudo selector can't be used to hide scrollbars via display: none

I've not released a new version yet because I would like to get a confirmation from your side whether everything works as expected.
Please visit the following pages and confirm the expected behavior:

• https://kingsora.github.io/OverlayScrollbars/ In your case you should see only the native system scrollbars here
• https://stackblitz.com/edit/overlayscrollbars Here you should also see the native system scrollbars
• https://stackblitz.com/edit/overlayscrollbars-9ryx6asg Here you should see only the custom scrollbars and no native system scrollbars

If you have some time left to confirm those behaviors, that would really help me to confidently push those changes out.
Thanks for raising this problem and for your time! :)

[mirabilos]

Please visit the following pages and confirm the expected behavior:

• https://kingsora.github.io/OverlayScrollbars/ In your case you should see only the native system scrollbars here

For the few elements with horizontal scrolling and the whole body? Yes.

• https://stackblitz.com/edit/overlayscrollbars Here you should also see the native system scrollbars
• https://stackblitz.com/edit/overlayscrollbars-9ryx6asg

These just say something about needing service workers, which I also vaguely remember disabling. Sorry, I cannot test that.

Here you should see only the custom scrollbars and no native system scrollbars

This is something I’m questioning though; at my previous employer’s, I saw that in Rocketchat, and it made the webäpp virtually unusable. I wouldn’t mind it so much (to please the “designers”) if there was a way for end users to disable it, e.g. by sending a documented command via F12 → Console (and it should ideally remember that state, so the user does not need to issue the command for every page load).

If you have some time left to confirm those behaviors, that would really help me to confidently push those changes out.
Thanks for raising this problem and for your time! :)

Yes, I have time left to look at things, and thank you for taking the time to work on this.