Closed Bug 949117 Opened 7 years ago Closed 7 years ago
Content verification for <input type="number"> doesn't work
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
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).
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.
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"/>
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.
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.
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.
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
You need to log in before you can comment on or make changes to this bug.