1949290 - Sliders thicker than chrome on https://robinhood.com/us/en/gold/

Status: NEW

(Web Compatibility :: Site Reports, defect, P3)

Description

[Marcelo Hernandez]

Attachment: Screenshot From 2025-02-19 16-37-31.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:136.0) Gecko/20100101 Firefox/136.0

Steps to reproduce:

Go to the website https://robinhood.com/us/en/gold/, see that in the "Let the numbers do the talking" box a bit below, scrollbars are too thick (even in troubleshoot mode). On chrome they look fine.

Specs:
Framework 13 AMD 7840u
Fedora Linux 41
GNOME 47 with 150% scaling

Actual results:

Scrollbars too thick

Expected results:

Scrollbars to be thin

Comment 1

[Marcelo Hernandez]

oops meant sliders, not scrollbars

Comment 2

[Francesco Lodolo [:flod]]

Tentatively moving to forms, although it might be a webcompat issue with CSS.

For the life of me, I can't figure out what's changing the aspect of the input range element. DevTools shows a CSS class assigned, removing it makes the slider thinner (still not similar to Chrome), but the rules seem irrelevant.

Comment 3

[Marcelo Hernandez]

(In reply to Francesco Lodolo [:flod] from comment #2)

For the life of me, I can't figure out what's changing the aspect of the input range element. DevTools shows a CSS class assigned, removing it makes the slider thinner (still not similar to Chrome), but the rules seem irrelevant.

If i add a CSS rule for height e.g.: input { height: 2px !important; } it looks more like Chrome, don't know if height is being changed somewhere?

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to Francesco Lodolo [:flod] from comment #2)

DevTools shows a CSS class assigned, removing it makes the slider thinner (still not similar to Chrome), but the rules seem irrelevant.

Solving this mystery: that's just because there are multiple copies of the same rule. So if you untick the styles (e.g. the background style) in one, then the declaration in the other copy of the rule gets applied instead (and the rendering doesn't change unless you untick all of them).

This is Robinhood depending on a -webkit prefixed CSS here -- specifically ::-webkit-slider-runnable-track (and also ::-webkit-slider-thumb { though that one matters less here).

They're specifying a custom background for the input element, which draws as the background for the track (as a gradient that fills in the bright white color up to the thumb); and then they limit the height of that track using that -webkit prefixed pseudo-class, which Firefox doesn't recognize.

Mozilla's rough equivalents are -moz-range-track and -moz-range-thumb. Though based on some local testing, it seems we ignore those pseudo-elements when appearance:none is applied (as it is here), so it's not quite a direct drop-in replacement.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 1

Comment 6

[Daniel Holbert [:dholbert]]

There are also standardized ways of referring to these pseudo-elements, which Firefox has implemented, but hidden behind an about:config pref (layout.css.modern-range-pseudos.enabled) from bug 1860666. (Looks like bug 1882253 tracks getting that pref enabled by default, eventually.)

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 2 (with moz-prefixed styles added to get the expected rendering in Firefox)

Here's a version where I've added the moz-prefixed styles (and removed appearance:none styling on the input so that they apply). In Firefox[1], this renders the same as testcase 1 does in Chromium.

Unfortunately it seems that removing appearance:none causes Chromium to disregard the styling on the thumb, so Chromium doesn't render this testcase the same way that they render testcase 1.

[1] with layout.css.modern-range-pseudos.enabled set to false, as it is by default

Comment 8

[Daniel Holbert [:dholbert]]

Let's morph this into a webcompat site-report, with bug 1950161 tracking the underlying behavior-difference between Firefox and other browsers.

Comment 9

[William Wen (:wwen)]

On first glance this breakage doesn't seem to be related to tracking protection. Does this issue go away if ETP is turned off? Maybe you meant to move it to Site Reports instead of Privacy: Site Reports?

Comment 10

[Daniel Holbert [:dholbert]]

Yup, that's what I meant to do - thanks!