::-webkit-scrollbar not working since a few days

[montsea999]

What type of issue is this?

Other

What information was incorrect, unhelpful, or incomplete?

In my angular app, I have a custom scroll, but since a few days, the custom style del ::-webkit-scrollbar stopped applying and I only see a default scrollbar. My source code has not been changed

What browsers does this problem apply to, if applicable?

No response

What did you expect to see?

The scroll bar as before. If this is not possible, at least be able to hide the arrow buttons

Did you test this? If so, how?

I have done several tests: If I go to an old commit I also see the default bar. If I go to any of the environments I also see the default bar.

Can you link to any release notes, bugs, pull requests, or MDN pages related to this?

No response

Do you have anything more you want to share?

No response

MDN URL

https://developer.mozilla.org/en-US/docs/Web/CSS/::-webkit-scrollbar

MDN metadata

MDN page report details

* Query: `css.selectors.-webkit-scrollbar` * Report started: 2024-02-10T22:43:28.022Z

[squivix]

I have the same problem on my Vue SPA web app.

Edit: Following this blog I fixed it.

[lukewarlow]

If you're using Chromium (Chrome/Edge etc) this is expected behaviour, as of Chrome 121 the standard properties are supported and as always the standard CSS overrides the non-standard.

I don't believe this warrants any changes to the BCD entry but perhaps a note on the content page itself would be useful?

[mcroba]

Is that expected that the scrollbar arrows are visible in Edge and Chrome (Windows only) whereas they are not in Firefox (that support scrollbar-* for a long time)?

On mac, they are not visible on Firefox, Chrome or Safari (obviously since it's not supported). I should probably open a ticket under the name css.properties.scrollbar-color

[lukewarlow]

That's also expected. Chromium on Windows uses a different scrollbar style to Firefox.

The test for whether it's an issue with the scrollbar properties is to remove them entirely and if the overall structure of the scrollbar is the same, then it's intentional.

Fwiw Chromium for windows has a "fluent scrollbar" flag that you can enable where the scrollbars should render more closely to Windows in general (and Firefox).

[mcroba]

Thank you for your feedback @lukewarlow.

My main issue is that with Chrome and Edge supporting now scrollbar-*, we start to see arrows in our custom scrollbar (which was not the case with webkit-scrollbar), so it's kind of a visual regression 😞

[montsea999]

In my case, I have also gone from having a nice scroll, without arrow buttons, with border-radius and custom color (in all environments, even in pro), to having an ugly scroll with arrow buttons, without border-radius and ugly gray color.

1. We had for Chrome and Edge: ::-webkit-scrollbar { // my pretty styles } ::-webkit-scrollbar-track { // my pretty styles } ::-webkit-scrollbar-thumb { // my pretty styles }

2. and for Firefox, the standard properties too: scrollbar-color: my-color; scrollbar-width: thin; and now with update 121, the standard properties crush the styles for Chrome and Edge and the custom styles are not seen.

The solution that I have found and that has worked well for me is to encapsulate the standard properties within a filter to detect that we are in Firefox. This way it only applies them while in that browser and does not crush the webkit styles in Chrome and Edge. // filter Firefox @-moz-document url-prefix() {

• { scrollbar-color: my-color; scrollbar-width: thin; } } And now I can see the pretty styles again in Chrome and Edge, and the standard styles in Firefox! 🙌

[lukewarlow]

There's a better way to conditionalise them than detecting Firefox.

@supports not (::-webkit-scrollbar) { } should do the trick (not checked exact syntax) in a more future proof way.

[mcroba]

Yes I finally went for that (similarly as mentioned here)

@supports not selector(::-webkit-scrollbar) {}

Hopefully, at some point, we will have a way to remove the arrows with scrollbar-*

[montsea999]

The way with the "@supports not" did not work for me and I found this other way that solved it for me. Apply the way that works for you while the problem is fixed ;)

[lukewarlow]

Are you able to close this issue as it's not a probably with the compat data, I've raised a separate content issue to make a more prominent note on the page itself.