Bugzilla

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.

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) 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).

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) 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).

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).

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).