Closed Bug 949117 Opened 7 years ago Closed 7 years ago

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

Categories

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

defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla29

People

(Reporter: ntim, Unassigned)

References

()

Details

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/
Component: Untriaged → DOM: Core & HTML
OS: Windows 8.1 → All
Product: Firefox → Core
Hardware: x86_64 → All
Blocks: 344616
Flags: needinfo?(jwatt)
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"/>
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
(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).
Duplicate of this bug: 949131
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.
Depends on: 949109
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"/>
Depends on: 827161
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.
Flags: needinfo?(jwatt)
QA Contact: jwatt
Fixed as part of fixing bug 949117.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
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.
Sorry, but there are too many things to uplift, so <input type=number> is going to be turned off in v28 (bug 962313).
(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.
Flags: needinfo?(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.
Flags: needinfo?(jwatt)
Keywords: verifyme
Verified as fixed using latest Aurora 29.0a2 (20140306004001) under Win 7 64-bit, Mac OSX 10.9 and Ubuntu 32-bit.
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.