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

RESOLVED FIXED in mozilla28

Status

()

defect
RESOLVED FIXED
6 years ago
Last year

People

(Reporter: jwatt, Assigned: jwatt)

Tracking

({dev-doc-needed})

Trunk
mozilla28
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

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.
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?
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.
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?
(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.
(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?
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).
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.)
That seems like it should work fine as long as the frame itself doesn't expect that content to be there.
Okay, great. That seems a lot simpler, safer, and seems to work great.
Assignee: nobody → jwatt
Attachment #8344402 - Flags: review?(bzbarsky)
Attachment #8344402 - Attachment is patch: true
Boris, roc is going to look at these, so ignore the review requests for now.
Fwiw, r=me too.
https://hg.mozilla.org/mozilla-central/rev/3bfbc5e93d42
https://hg.mozilla.org/mozilla-central/rev/1682d636c3c5

Thanks guys!
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
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
Keywords: dev-doc-needed
Flags: in-testsuite?
Does this need (or have) a test? Thanks!
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)
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.
Flags: needinfo?(jwatt)
No, it's not in any specification, unfortunately.
Flags: needinfo?(jwatt)
(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.
Depends on: 1140216
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.