Closed Bug 1432935 Opened 2 years ago Closed 9 months ago

Support -webkit-scrollbar styles for webcompat

Categories

(Core :: CSS Parsing and Computation, enhancement, P2)

enhancement

Tracking

()

RESOLVED WONTFIX
Webcompat Priority P1
Tracking Status
firefox60 --- affected

People

(Reporter: wisniewskit, Assigned: denschub)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [webcompat:p1][webkit-scrollbar])

User Story

Business driver: Top site (and long-tail) interop: Gmail, GCal, Twitch, Youtube
The use of -webkit-scrollbar CSS to hide scrollbars, color them, and otherwise manipulate their basic appearance seems common enough that we ought to try to standardize these bits of CSS (Edge supports their own prefixed variants, so we're the only engine without support for anything like them, plus there are sites which do not even bother with prefixes other than -webkit).

At the very least I would suggest supporting the ability to hide scrollbars with rules like this:

  selector::-webkit-scrollbar { display:none }

Note that there is some recent movement/interest [1] in speccing out at least the color-oriented properties, so this might be a good time to hammer out the details and add support to at least the Compatibility Standard.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=77790#c214
Flags: webcompat+
Whiteboard: [webcompat][webkit-scrollbar] → [webcompat:p1][webkit-scrollbar]
[ Triage 2017/02/20: P2 ] Marking this P2 along with the other -webkit-* properties we're pushing on.
Priority: -- → P2
User Story: (updated)
I'm to some extent against implementing all the pseudo-elements of scrollbar. I guess implementing a small subset of them might be fine, but providing the whole power of touching every details of the scrollbar is probably not.

I would rather we start implementing CSS Scrollbars spec and then ask developers to play with it to see if they like it. Eventually, we may want to map some of the scrollbar pseudo-element ability to those properties for long-tails when possible.
Blocks: 1170789
Depends on: 1431246
(In reply to Xidorn Quan [:xidorn] UTC+10 from comment #2)
> I guess implementing a small subset of them might be fine, but
> providing the whole power of touching every details of the scrollbar is
> probably not.

I wonder if we can get away with a "good enough" subset, and map that to CSS Scrollbars. 

-webkit-scrollbar seems like most important, since it's often used to hide the scrollbar, or set a width a layout depends on. We should probably attempt some kind of survey to see how these are used in the wild and if only supporting a subset would create problems.
Whiteboard: [webcompat:p1][webkit-scrollbar] → [webcompat:p2][webkit-scrollbar]
Blocks: 852146
Blocks: 1305028
Assigning to Xidorn as he is working on bug 1460109 and dependencies. Even if we end up deciding that we will not emulate -webkit-scrollbar, we are very much working on this problem.
Assignee: nobody → xidorn+moz
Status: NEW → ASSIGNED
Whiteboard: [webcompat:p2][webkit-scrollbar] → [webcompat:p1][webkit-scrollbar]
There are currently 8 webcompat issues in See Also of this bug.

I'll try to summarize what are the problem, whether they have been fixed, and whether we can use shim based on scrollbar properties to fix them (as if they haven't fixed them).

* webcompat/web-bugs#12356 - gitter.im
Site fixed: no
Problem: hide scrollbar via ::-webkit-scrollbar { display: none }
Possible shim: can be done with shim like mozilla/webcompat-addon#33.

* webcompat/web-bugs#2767 - twitch.tv
Site fixed: yes
Problem: hide scrollbar via ::-webkit-scrollbar { width: 0; height: 0 }
Possible shim: the same shim above may be used with some additional rule

* webcompat/web-bugs#3816 - cdn.kotsovolos.gr
Site fixed: probably no
Problem: hide scrollbar via dynamically inserting ::-webkit-scrollbar { display: none }
Possible shim: the same shim may need some specialization to handle the dynamic insertion, but allowing arbitrary webkit-prefixed pseudo-element (bug 1486325) may be itself enough.

* webcompat/web-bugs#8626 - readthedocs.org
Site fixed: yes
Problem: hide scrollbar via using negative margin with appearance: none
Possible shim: need specialized stylesheet.

* webcompat/web-bugs#8030 - preview.webflow.com
Site fixed: no
Problem: block Firefox due to lack of ability to style scrollbar
Possible shim: no idea. If they just want to have different color, we can apply specialized stylesheet with user agent overriding.

* webcompat/web-bugs#2429 - itunes.apple.com
Site fixed: yes
Problem: style scrollbar with border image and width
Possible shim: would need advanced shim to simulate the whole scrollbar.

* webcompat/web-bugs#7919 - discordapp.com
Site fixed: no
Problem: advanced scrollbar styling on Chrome, imperfect scrollbar covering with custom scrollbar on Firefox
Possible shim: specialized stylesheet to help hiding the scrollbar so that their custom scrollbar can be used perfectly

* webcompat/web-bugs#17828 - keep.google.com
Site fixed: no
Problem: shrink the scrollbar width with ::-webkit-scrollbar
Possible shim: specialized stylesheet to apply scrollbar-width: thin to the affected element


So in the 8 issues, 3 have been fixed by the sites. In the 5 unfixed ones, 4 can probably be fixed via some specialized stylesheet shim with scrollbar-width property. preview.webflow.com may need specialized stylesheet shim as well as UA override.
Flags: needinfo?(miket)
Flags: needinfo?(miket)
My general proposal for fixing this kind of webcompat issue is to create a specific injection stylesheet for each site we want to fix. We may need to wait for the scrollbar properties to ship since it doesn't seem to me that we insert the stylesheets as chrome stylesheets, so we have to wait for the properties to be available in content.

The script was an attempt to create a generalized solution, but there doesn't seem to be enough websites to justify that extra complexity. A specialized stylesheet fixup for each site should be straightforward, and we can also hand such stylesheets to the websites when outreaching to help them fix their sites.
(In reply to Panos Astithas (he/him) [:past] (please ni?) from comment #4)

> Assigning to Xidorn as he is working on bug 1460109 and dependencies. Even
> if we end up deciding that we will not emulate -webkit-scrollbar, we are
> very much working on this problem.

Now that bug 1492012 has landed, does it remain the plan to NOT emulate -webkit-scrollbar and do specialized stylesheet fixups as needed?
Yes, the current plan is what Xidorn outlined in comment 6. Note that these will be stylesheet fixups that we apply through our web compat system add-on code on incompatible sites.
I don't think Xidorn is planning to work on this, but feel free to reassign if I am mistaken.
Assignee: xidorn+moz → nobody
Status: ASSIGNED → NEW
Firefox 64 has been already released.  Thomas, are you going to work on the fixup thing in comment 8?  Or should I ask Mike Taylor who will work on it?
Flags: needinfo?(wisniewskit)
Actually Mike has already asked me to take a look at this, so I'll do so ASAP.
Flags: needinfo?(wisniewskit)

Assigning per comment 11.

Assignee: nobody → twisniewski
Status: NEW → ASSIGNED

I believe Dennis will pick this up.

Assignee: twisniewski → dschubert

See bug 1547409. Migrating webcompat priority whiteboard tags to project flags.

Webcompat Priority: --- → P1
See Also: → 1561299

In Bug 1561299, our current plan is to just intervene using scrollbar-width for important sites. So let's WONTFIX here.

Status: ASSIGNED → RESOLVED
Closed: 9 months ago
Resolution: --- → WONTFIX
See Also: → 1623632
You need to log in before you can comment on or make changes to this bug.