949117 - Content verification for <input type="number"> doesn't work

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Tim Nguyen :ntim]

Number inputs allow typing letters in it, and pseudo selectors such as :invalid or :valid don't fully work.
Test case : http://jsfiddle.net/ntim/3RPTE/

Comment 1

[Tim Nguyen :ntim]

I noticed that content verification does work when you prefill the value before page load using the value attribute. So content verification will work if you do this : <input type="number" value="Hello world"/>

Comment 2

[Markus Popp]

I filed a report of what I guess is the same bug moments before I noticed yours:

https://bugzilla.mozilla.org/show_bug.cgi?id=949131

Comment 3

[Tim Nguyen :ntim]

(In reply to Markus Popp from comment #2)
> I filed a report of what I guess is the same bug moments before I noticed
> yours:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=949131

Please mark your bug as duplicate of this one (I don't have the permissions to edit your bug).

Comment 5

[Markus Popp]

So we have all information related to this bug in one place, here is again the text of my simultaneously reported bug 949131:

With a form like this:

<form action="<?php print $_SERVER['PHP_SELF']; ?>" method="post">
    <input type="number" name="num" step="any" placeholder="Enter a number" autofocus><br>
    <input type="submit" name="s" value="Submit Form">
</form>

... I can enter any value and still submit the form.

Try at http://var.mpopp.net/number-bug/index.php

Enter a value like "abc", Firefox Nightly still submits the form (Chrome 31.0 refuses to do so). The same happens when you enter "3,5" (output will be "Entered number was 0" after converting the input value to a float), Chrome refuses to submit that too.

Even if I reduce the input field to <input type="number"> it still triggers.

Comment 6

[Tim Nguyen :ntim]

The content validation previously worked. But now that the value is now type into the anonymous <input type="text"/>. It doesn't work. A solution would be delegating current validation code to the anonymous <input type="text"/>

Comment 7

[Jonathan Watt [:jwatt]]

On the page at:

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html

the spec says that we must sanitize when a 'value' content attribute causes the value of the element to change:

  The value content attribute gives the default value of the input
  element. When the value content attribute is added, set, or removed,
  if the control's dirty value flag is false, the user agent must set
  the value of the element to the value of the value content attribute,
  if there is one, or the empty string otherwise, and then run the
  current value sanitization algorithm, if one is defined.

and when the element is initially created:

  When an input element is first created, the element's rendering
  and behavior must be set to the rendering and behavior defined for
  the type attribute's state, and the value sanitization algorithm,
  if one is defined for the type attribute's state, must be invoked.

On the page at:

http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html

the spec says that we must sanitize when the 'value' IDL property is assigned to:

  On getting, it must return the current value of the element. On
  setting, it must set the element's value to the new value, set
  the element's dirty value flag to true, invoke the value
  sanitization algorithm...

There is no longer any text that requires sanitization of the element's value whenever it changes though, and a badInput validity state has been introduced to the spec that allows for non-sanitized values. Specifically, it seems like it would be a good idea not to sanitize the value when the user is entering input, and if the input is invalid make use of the new badInput validity state.

I've got patches for that in bug 827161.

Comment 8

[Jonathan Watt [:jwatt]]

Fixed as part of fixing bug 949117.

Comment 9

[Markus Popp]

Should this be uplifted to Firefox 28 (now in beta)? Looks like a significant bug fix that should be included when <input type="number"> is (hopefully) released in 6 weeks.

Comment 10

[Jonathan Watt [:jwatt]]

Sorry, but there are too many things to uplift, so <input type=number> is going to be turned off in v28 (bug 962313).

Comment 11

[Tim Nguyen :ntim]

(In reply to Jonathan Watt [:jwatt] from comment #8)
> Fixed as part of fixing bug 949117.

I can still type letters into the number input.

Comment 12

[Jonathan Watt [:jwatt]]

That's expected. The validation code will now prevent the form from submitting though, and when you switch focus away from the input it will be highlighted as invalid.

Comment 13

[Petruta Horea [:phorea], Desktop QA]

Verified as fixed using latest Aurora 29.0a2 (20140306004001) under Win 7 64-bit, Mac OSX 10.9 and Ubuntu 32-bit.