2027840 - -webkit-scrollbar width/height style rules do not behave correctly

Status: RESOLVED DUPLICATE of bug 2029246

(Core :: Layout: Scrolling and Overflow, defect)

Description

[Sam Johnson]

Attachment: Example case where scrollbars are unintentionally visible after bug 1977511

After bug 1977511, setting a width and/or height on -webkit-scrollbar now shows the non-overlay scrollbar. However, I believe this behavior is not entirely correct.

When width/height are set on -webkit-scrollbar, in Safari and Chrome, the space for the scrollbar gets allocated as specified, but the scrollbar itself is not actually shown unless -webkit-scrollbar-thumb, -webkit-scrollbar-track, etc have styles specified. This causes scrollbars to be drawn in Firefox unintentionally. I have attached a simplified example to illustrate.

Ideally, if this style is going to be respected, the -webkit-scrollbar-thumb and/or -webkit-scrollbar-track background should also be respected, as these are almost always used together with -webkit-scrollbar.

Comment 1

[Sam Johnson]

Attachment: behavior difference firefox-chrome-safari.png

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1977511

:hiro, since you are the author of the regressor, bug 1977511, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 3

[Daniel Holbert [:dholbert]]

This might be sort-of a dupe of bug 1432935, but maybe worth keeping separate if there are real-world issues identified...

(In reply to Sam Johnson from comment #0)

After bug 1977511, setting a width and/or height on -webkit-scrollbar now shows the non-overlay scrollbar. However, I believe this behavior is not entirely correct.

"correct" is not really well-defined here; -webkit-scrollbar is a nonstandard legacy feature. So "correct" essentially means "perfect compatibility with Chromium/WebKit on this nonstandard feature, and that's a non-goal for us at the moment (see below).

Note also that Firefox users who have the "always show scrollbars" feature enabled in their OS have always seen essentially the same result as your screenshot shows for current Firefox Nightly (going back ~forever).

When width/height are set on -webkit-scrollbar, in Safari and Chrome, the space for the scrollbar gets allocated as specified, but the scrollbar itself is not actually shown unless -webkit-scrollbar-thumb, -webkit-scrollbar-track, etc have styles specified. This causes scrollbars to be drawn in Firefox unintentionally.

Do you know if sites actually do this (and if so, why)? I can imagine sites e.g. using this to allocate space for a scrollbar, and then using their own custom code to draw their own "scrollbar-thumb" -- is that the sort of thing you're talking about, and do you have examples of sites actually doing that?

Ideally, if this style is going to be respected, the -webkit-scrollbar-thumb and/or -webkit-scrollbar-track background should also be respected, as these are almost always used together with -webkit-scrollbar.

For perfect compatibility, that would be ideal, yeah -- but that adds a substantial amount of implementation-complexity, so we haven't elected to take on that burden right now. See bug 1432935 comment 17 for some notes on this.

So for now, given the nature of issues that we've run into related to these styles, we've elected to take a middle ground and not aim for perfect compatibility -- we're treating ::-webkit-scrollbar { width: <nonzero-length> } as just forcing Firefox to opt into a traditional scrollbar (which some Firefox users would already be getting anyway, if they have "always show scrollbars" enabled) for a particular element. This isn't intended to be perfect support, but it's meant to avoid pitfalls where we suspect sites are using this syntax as a way to opt-out-of overlay scrollbars (which we've seen in some cases as discussed in bug 1977511 comment 0, and which can be important to avoid usability issues like superimposed scrollbars from nested scrollable areas).

Comment 4

[Sam Johnson]

Thanks for the detailed explanation, I really appreciate it!

(In reply to Daniel Holbert [:dholbert] from comment #3)

Do you know if sites actually do this (and if so, why)?

I do not, however after seeing many new scrollbars this morning, I started playing with things, noticed this behavior, and here we are :)

For perfect compatibility, that would be ideal, yeah -- but that adds a substantial amount of implementation-complexity, so we haven't elected to take on that burden right now. See bug 1432935 comment 17 for some notes on this.

So for now, given the nature of issues that we've run into related to these styles, we've elected to take a middle ground and not aim for perfect compatibility -- we're treating ::-webkit-scrollbar { width: <nonzero-length> } as just forcing Firefox to opt into a traditional scrollbar (which some Firefox users would already be getting anyway, if they have "always show scrollbars" enabled) for a particular element. This isn't intended to be perfect support, but it's meant to avoid pitfalls where we suspect sites are using this syntax as a way to opt-out-of overlay scrollbars (which we've seen in some cases as discussed in bug 1977511 comment 0, and which can be important to avoid usability issues like superimposed scrollbars from nested scrollable areas).

That's fair enough! I haven't noticed any new usability issues from this new support, just "things not looking great" on sites using these styles, such as Discord. The appearance and behavior ends up being significantly different from Chrome, which isn't ideal, but if perfect compatibility is a non-goal, I am good closing this. However, I do worry a bit that others will have a similar "something isn't quite right" reaction when this reaches beta/release.

Comment 5

[Daniel Holbert [:dholbert]]

Thanks! Are there other prominent sites (besides Discord) where you noticed traditional scrollbars appearing and perceived them as a step backwards?

For prominent sites...

• ...that use ::-webkit-scrollbar with nonzero width (triggering this new behavior) but do so purely cosmetically (not for any usability issue with superimpmosed-scrollbars)
• ...where users-who-have-overlay-scrollbar might perceive newly-OS-themed tradititional-scrollbars as a step backwards
• ...where the site has enough usage to merit special intervention

...then we could perhaps add some site-specific CSS to Firefox, to stomp on any webkit-scrollbar styles (to restore overlay scrollbars). We'd need to think a bit carefully about this, and of course this doesn't scale to arbitrarily-many sites (but might be worth doing in specific cases of popular sites that are triggering this new behavior and where traditional scrollbars seem likely to feel clunkier for users-with-overlay-scrollbars).

Comment 6

[Sam Johnson]

(In reply to Daniel Holbert [:dholbert] from comment #5)

Thanks! Are there other prominent sites (besides Discord) where you noticed traditional scrollbars appearing and perceived them as a step backwards?

For prominent sites...

• ...that use ::-webkit-scrollbar with nonzero width (triggering this new behavior) but do so purely cosmetically (not for any usability issue with superimpmosed-scrollbars)
• ...where users-who-have-overlay-scrollbar might perceive newly-OS-themed tradititional-scrollbars as a step backwards
• ...where the site has enough usage to merit special intervention

I've been looking for more instances of this over the past few days, and while there are several places where I am newly seeing non-overlay scrollbars, I believe Discord is the only one I have seen so far that meets all of the above criteria. In most instances, the non-overlay scrollbar is quite welcome. I think Discord is a bit of a special case because they use :hover to make the scrollbar thumb and track conditionally visible in Chrome.

Comment 7

[Daniel Holbert [:dholbert]]

Thanks. I'm going to open a fresh bug to consider suppressing Discord's webkit-scrollbar styles (to avoid opting them into our partial support for webkit scrollbar styles, since that might be perceived as a step backwards in their case); and I'll mark this bug as a duplicate of that.

Comment 8

[Daniel Holbert [:dholbert]]

Filed bug 2029246.