1663819 - moz-range-thumb cannot be relatively-positioned

Status: REOPENED

(Core :: CSS Parsing and Computation, defect)

Description

[daniel.livingston]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36

Steps to reproduce:

Stacked input range sliders, with z-index set on the thumb to simulate a multi-range sider e.g. http://projects.verou.me/multirange/

Actual results:

z-index set on pseudo element moz-range-thumb seem to be ignored

Expected results:

The thumb of a lower slider should be stacked according to z-index on top of the track of the upper slider for instance, as per Firefox less than 80

Comment 1

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Emilio Cobos Álvarez [:emilio]]

That polyfill was relying on a Firefox bug. It broke with bug 1256980.

However they can't do the same thing they do in WebKit because we enforce their position to be static, so you can't relatively-position the thumbs. We should loosen that restriction.

Comment 3

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1663819 - Loosen the styling restrictions on meter and input[type=range] pseudo-elements. r=jwatt,#layout-reviewers

These were there to prevent crashes because when the type of the frame
changes dynamically we would mess up and fail to find the right
insertion point.

We deal with this correctly nowadays:

https://searchfox.org/mozilla-central/rev/b2716c233e9b4398fc5923cbe150e7f83c7c6c5b/layout/base/nsCSSFrameConstructor.cpp#8521-8536

And the list was never exhaustive in the first place (e.g., writing-mode
can also cause us to reframe, and so do a bunch of other properties). So
there's no real reason to be so strict anymore.

Also change ::-moz-complex-control-wrapper while at it too, because it's
not web exposed so there's no need for those declarations in the first
place.

Comment 4

[Emilio Cobos Álvarez [:emilio]]

After this fix, the polyfill needs to be updated to use position: relative instead of / as well as transform: scale(1) which is what it was using.

Comment 5

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

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

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b0587b321c5b
Loosen the styling restrictions on meter and input[type=range] pseudo-elements. r=jwatt

Comment 7

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/b0587b321c5b

Comment 8

[Emilio Cobos Álvarez [:emilio]]

(To address mats' comment)

Comment 9

[Natalia Csoregi [:nataliaCs]]

Backed out: https://hg.mozilla.org/integration/autoland/rev/bf6d283e86ccfdcfff5fa2fb2a2f4aee4a3e94c8

Comment 10

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Backout merged: https://hg.mozilla.org/mozilla-central/rev/bf6d283e86cc

Comment 11

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

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:emilio, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 12

[Dyne Hash]

Had some progress.
I tried to put a text in the middle of the input range, but the text is in front making it difficult to move the range-thumb.