947728 - Provide a way for content to hide <input type=number>'s spinner

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Jonathan Watt [:jwatt]]

We could turn on <input type=number> for v28, except that I find myself in a catch 22. smaug thinks we need to give content a way to hide the spinner before we ship <input type=number>. But in bug 930010 we decided to disallow content from using <input type=number>'s pseudo-elements, so it can't style ::-moz-number-spin-box with |display:none|.

We could do something like hide the spinner for <input type=number spinner=off>, although that introduces some presentation in a non-CSS way.

Another alternative might be to introduce a new value for -moz-appearance of 'number-input', make that value the value set by the UA style sheet for number controls, and have the spinner show for that value. If a user instead specifies |-moz-appearance:textfield| for a number input we could hide the spinner. That probably requires a hack along the lines of bug 946262 though.

Comment 1

[Boris Zbarsky [:bzbarsky]]

How much logic is in the number frame?  If we made -moz-appearance changes reframe and made -moz-appearance:textfield on a number input just create a text control frame, would that work?

Comment 2

[Jonathan Watt [:jwatt]]

nsNumberControlFrame and the handling for NS_FORM_INPUT_NUMBER in HTMLInputElement are very intertwined. To make that work I think we'd need to also flip HTMLInputElement::mType to NS_FORM_INPUT_TEXT as if the pref was off. I'll take a look at exactly what would be required, but I think it would be a fair bit of work to avoid that.

Comment 3

[Boris Zbarsky [:bzbarsky]]

OK. That's pretty unfortunate.  :(  In an ideal world, all the behavior logic would be in the content, and the frame would just draw things....

Flipping the type would make the control not enforce constraints on the input, which is not desirable, right?

Comment 4

[Jonathan Watt [:jwatt]]

(In reply to Boris Zbarsky [:bz] from comment #3)
> OK. That's pretty unfortunate.  :(  In an ideal world, all the behavior
> logic would be in the content, and the frame would just draw things....

Right. Knowledge about the content and structure of the anonymous tree is currently restricted to the frame that creates it though.

> Flipping the type would make the control not enforce constraints on the
> input, which is not desirable, right?

Right.

Comment 5

[Jonathan Watt [:jwatt]]

(In reply to Jonathan Watt [:jwatt] from comment #2)
> nsNumberControlFrame and the handling for NS_FORM_INPUT_NUMBER in
> HTMLInputElement are very intertwined.

On closer inspection it looks like all the do_QueryFrame checks that I added to HTMLInputElement do exactly what we would need already, so this may well work. I'm building some patches and will test shortly.

One thing I'm not clear on is how best to handle the reframing. We could do something like this in nsStyleDisplay::CalcDifference, but it seems like it would be best to restrict the reframing to <input type=number>:

  if ((mAppearance == NS_THEME_TEXTFIELD &&
       aOther.mAppearance != NS_THEME_TEXTFIELD) ||
      (mAppearance != NS_THEME_TEXTFIELD &&
       aOther.mAppearance == NS_THEME_TEXTFIELD)) {
    // This is for <input type=number> where we allow authors to specify a
    // |-moz-appearance:textfield| to get a control without a spinner. (The
    // spinner is present for |-moz-appearance:number-input| but also other
    // values such as 'none'.) We need to reframe since we want to use
    // nsTextControlFrame instead of nsNumberControlFrame if the if the author
    // specifies 'textfield'.
    return nsChangeHint_ReconstructFrame;
  }

Maybe there's something I can do from nsNumberControlFrame::DidSetStyleContext and nsTextControlFrame::DidSetStyleContext to trigger a reframe?

Comment 6

[Boris Zbarsky [:bzbarsky]]

The right way to do it is just from CalcDifference, imo.  In practice, changes to/from that appearance generally reframe anyway (because <input> reframes on changes to the "type" attribute no matter what).

Comment 7

[Jonathan Watt [:jwatt]]

I'm still working on it, but I've gone back to being unsure that I can make using nsTextControlFrame work. I'd need IsSingleLineTextControl to return true in some places and false in others.

It seems that the nsNumberControlFrame has a valid styleContext by the time nsNumberControlFrame::CreateAnonymousContent is called, so how about instead I check that context's mAppearance and skip creating the ContentInfos for the spinner elements if it's NS_THEME_TEXTFIELD? Do you see any issues with that approach, Boris. (Plus reframing of course.)

Comment 8

[Boris Zbarsky [:bzbarsky]]

That seems like it should work fine as long as the frame itself doesn't expect that content to be there.

Comment 9

[Jonathan Watt [:jwatt]]

Attachment: patch to introduce a new value 'number-input' for -moz-appearance

Okay, great. That seems a lot simpler, safer, and seems to work great.

Comment 10

[Jonathan Watt [:jwatt]]

Attachment: patch to make the default value for -moz-appearance on <input type=number> 'number-input', and make the value 'textfield' hide the spinner

Comment 11

[Jonathan Watt [:jwatt]]

Attachment: patch to make the default value for -moz-appearance on <input type=number> 'number-input', and make the value 'textfield' hide the spinner

Comment 12

[Jonathan Watt [:jwatt]]

Boris, roc is going to look at these, so ignore the review requests for now.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Fwiw, r=me too.

Comment 14

[Jonathan Watt [:jwatt]]

https://hg.mozilla.org/mozilla-central/rev/3bfbc5e93d42
https://hg.mozilla.org/mozilla-central/rev/1682d636c3c5

Thanks guys!

Comment 15

[Matt Brubeck (:mbrubeck)]

Should/can we document this on MDN somewhere?

https://developer.mozilla.org/en-US/docs/Web/CSS/-moz-appearance would be one good place, but it would also be useful to have something findable from https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Input

Comment 16

[Liz Henry (:lizzard) (relman/hg->git project)]

Does this need (or have) a test? Thanks!

Comment 17

[Daniel Holbert [:dholbert]]

It doesn't look like it currently has a test, based on
http://mxr.mozilla.org/mozilla-central/search?string=textfield&find=layout%2Freftests%2Fforms%2Finput%2Fnumber
...but there will soon be several reftests whose testcases *depend* on this (and would fail if this weren't working) -- the reftests in bug 951310.

So this will soon have a test, once that bug is closed.

(still might be worth adding an explicit no-nonsense test here, though)

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Is this described by any specification?  It seems like it needs to be; evangelizing sites like the one in bug 1000400 to use Mozilla-specific CSS isn't great.

Comment 19

[Jonathan Watt [:jwatt]]

No, it's not in any specification, unfortunately.

Comment 20

[Hallvord R. M. Steen [:hallvors]]

(In reply to David Baron [:dbaron] (Away/Busy May 10-22) (UTC+9) from comment #18)
> evangelizing sites like the one in bug 1000400 to use Mozilla-specific CSS
> isn't great.

+1

Seems the main problem here (see screenshot in bug 1000400 and friends) is that when the input is styled to be very small, it's entirely filled by the spinners so you can't see the number. That looks like a plain bug to me - can't we just set some max-width:10% on the spinners, or automatically hide them if the input's width is less than what it takes to show one character with the given font and size, or something like that? I don't see why authors should have to add special CSS at all.