1492043 - number input's inner spin button always shown with '-webkit-appearance: none'

Status: RESOLVED WORKSFORME

(Core :: Layout: Form Controls, defect, P3)

Description

[Cheng-You Bai [:cybai] UTC+9]

Attachment: Screenshot.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:64.0) Gecko/20100101 Firefox/64.0
Build ID: 20180917220115

Steps to reproduce:

Check how following html rendered

```
<style>
  input[type=number] {
    -webkit-appearance: none;
  }

  input[type=number]::-webkit-inner-spin-button,
  input[type=number]::-webkit-outer-spin-button {
    -webkit-appearance: none;
    margin: 0;
  }
</style>

<input type="number" />
```


Actual results:

The inner spin button will show even appearance is specified as none


Expected results:

Not sure if this is a bug, but in Chrome, input[type=number] will not show the inner spin button when appearance is specified as `none`.

(Check the Screenshot.png)

Comment 1

[Emilio Cobos Álvarez (:emilio)]

So in Gecko you can prevent the spin buttons from showing up if you use -moz-appearance: textfield.

In chrome, the spin buttons will show unless you specify -moz-appearance: none on the pseudo-elements, which is what makes them disappear. I'm not sure we want to implement that behavior..

Jonathan, do you see something actionable here? I asked Cheng-You to file a bug because they mentioned that a website they developed was broken on Nightly because of this (due to the -webkit-appearance bits).

Cheng-You, what happens when -webkit-appearance is disabled? How did you hide the spin buttons?

Comment 2

[Sean Voisen (:svoisen)]

Did this really break as a result of -webkit-appearance? With -webkit-appearance disabled and the testcase above the spin buttons will still show. With -webkit-appearance enabled and -webkit-appearance: none on the numeric input, only the border style will change (to beveled).

Setting to P3 since this doesn't seem like a regression caused by -webkit-appearance in Nightly, but if it is feel free to bump to P2 if I'm mistaken.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Depends on my question to Cheng-You. In particular, if you used to have:

input[type="number"] {
    -moz-appearance: textfield;
    -webkit-appearance: none;
}

It'd break.

Comment 4

[Cheng-You Bai [:cybai] UTC+9]

Sorry for misleading; let me provide a more correct test case.

Yes, the test case in our website is similiar to the one emilio shown in Comment 3.

Here is the correct one and it would break with this test case:

```
<style>
input[type=number] {
  -moz-appearance: textfield;
}

input[type=number]::-webkit-inner-spin-button,
input[type=number]::-webkit-outer-spin-button {
  -webkit-appearance: none;
  appearance: none;
  margin: 0;
}

.wrapper .number-input {
  -webkit-appearance: none;
}
</style>

<div class="wrapper">
  <input type="number" class="number-input" />
</div>
```

Comment 5

[Jonathan Watt [:jwatt]]

Attachment: Bug 1492043. Hide number input's spin buttons for `-moz/webkit-appearance: none`. r?emilio

Comment 6

[Jonathan Watt [:jwatt]]

Cheng-You, I think there's been some confusion or our/my part. We very recently made changes to make -webkit-appearance (as opposed to -moz-appearance) work in Firefox. Currently that support is only in Nightly and Beta, but hasn't reached Release yet. This support will be in the next release version of Firefox unless an issue is reported that is serious enough for us to defer that.

The assumption that I'd had here was that this bug report was a regression due to our addition of -webkit-appearance support, and that we had broken something that used to work for you. I'm guessing that that is not the case, and that the timing of you reporting this bug is just a coincidence, and that actually this is not something that used to work and has broken, but rather just a request to match Chrome's behavior. Can you confirm/refute that just so we're clear? Thanks. :)

Comment 7

[Jonathan Watt [:jwatt]]

Ah, I understand now. So previously Firefox would only recognize '-moz-appearance: textfield' and the spin buttons would be hidden, but now it also recognizes '-webkit-appearance: none', which with the way your rules are set up has higher specificity, and now you end up with a computed value of 'none' instead of 'textfield' which, while it removes the native theming as you seem to want to remove, now unfortunately also leaves the spin buttons showing.

This is a clear regression from enabling the -webkit-appearance alias (bug 1480073). That said, this doesn't seem like a big enough issue to block shipping that alias given all the websites that it fixes.

Given that, I don't think there's much we can do. I can only suggest that you add a new line containing '-moz-appearance: textfield' directly after the line containing '-webkit-appearance: none' to override that value for Firefox.

(Side node: even if we gave access to the pseudo-elements (bug 978320) it would still require anyone affected by this issue to update their content to start theming those pseudo-elements and to stop using '-appearance: textfield'.)

Comment 8

[Cheng-You Bai [:cybai] UTC+9]

Jonathan, for the case in the website I worked on, I've specified '-moz-appearance: textfield' for it and it works fine!

About the regression, I'm not sure if this is a bug but following code will work fine for the appearance textfield

```
<style>
  input[type=number] {
    -moz-appearance: textfield;
  }

  input[type=number]::-webkit-inner-spin-button,
  input[type=number]::-webkit-outer-spin-button {
    -webkit-appearance: none;
    appearance: none;
    margin: 0;
  }

  .number-input {
    -webkit-appearance: none;
  }
</style>

<input type="number" class="number-input" />
```

I assumed the only difference between this example and the one I provided in Comment 4 is the one in Comment 4 is inside a div.
In my understanding, this should work as the one in Comment 4?

If I have any misunderstanding or you need me to provide more information, please let me know! Thanks!

Comment 9

[Jonathan Watt [:jwatt]]

From my side I have all the info I need, thanks, Cheng-You.

To answer your question, the key difference is not the removal of the <div>, but rather the change from:

  .wrapper .number-input {
    ...
  }

to:

  .number-input {
    ...
  }

The first of these has higher "specificity"[1] than the input[type=number] rule and therefore it takes precedence. The second has lower "specificity" than the input[type=number] rule and therefore it is overridden. So the examples in comment 4 and comment 8 are expected to behave differently, because that's how CSS "cascade" is defined to work.

1. https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity

Comment 10

[Jonathan Watt [:jwatt]]

To be clear about my suggestion in comment 7, I'm suggesting that you should be able to fix things in your case by changing:

  .wrapper .number-input {
    -webkit-appearance: none;
  }

to:

  .wrapper .number-input {
    -webkit-appearance: none;
    -moz-appearance: textfield;
  }

Comment 11

[Jonathan Watt [:jwatt]]

It being important that the -moz-appearance line comes *after* the -webkit-appearance line in that rule.

Comment 12

[Cheng-You Bai [:cybai] UTC+9]

Jonathan, ah! That makes sense! Thanks for your clarification!

I didn't know very well on selector's specificity.

Then, though I've used the solution in Comment 10, I still would like to say the solution looks very reasonable for me now!

For Comment 11, thanks for reminder! I understand the latter one will be applied!

Comment 13

[Dennis Schubert [:denschub]]

Tom, can you take a look at this, and maybe build an isolated testcase if this is still an issue?

Comment 14

[Thomas Wisniewski [:twisniewski]]

This doesn't really sound like something that can be "fixed" by Firefox, as opposed to it being good for users to understand which CSS appearance values they need to use to achieve their desired effect (including for the known breakage in the see-alsos here).

That is, this might be good to document in a knowledge base entry for how various appearance values work across browsers, and the known issues related to them, but to me this bug seems safe to close.