Last Comment Bug 636737 - Implement valueAsNumber for <input type='number'>
: Implement valueAsNumber for <input type='number'>
Status: RESOLVED FIXED
: doc-bug-filed, html5
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: mozilla16
Assigned To: Mounir Lamouri (:mounir)
:
Mentors:
Depends on: 636750
Blocks: 639661 344616
  Show dependency treegraph
 
Reported: 2011-02-25 08:17 PST by Mounir Lamouri (:mounir)
Modified: 2013-04-27 15:09 PDT (History)
9 users (show)
mounir: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch v1 (10.06 KB, patch)
2011-02-25 08:40 PST, Mounir Lamouri (:mounir)
no flags Details | Diff | Review
Patch v1.1 (9.93 KB, patch)
2011-02-28 09:06 PST, Mounir Lamouri (:mounir)
jonas: review+
Details | Diff | Review

Description Mounir Lamouri (:mounir) 2011-02-25 08:17:13 PST
Actually, we don't want that. Olli and I tried to have it removed from the specs but I wrote a patch a long time ago so I'm going to refresh it and attach it here.
Bug against the specs: http://www.w3.org/Bugs/Public/show_bug.cgi?id=11887
Comment 1 Mounir Lamouri (:mounir) 2011-02-25 08:40:31 PST
Created attachment 515087 [details] [diff] [review]
Patch v1

I'm asking a review but this might be canceled and the bug marked as WONTFIX if the specs remove this attribute.
Comment 2 Mounir Lamouri (:mounir) 2011-02-28 09:06:31 PST
Created attachment 515641 [details] [diff] [review]
Patch v1.1

Use double instead of float.
Comment 3 Olli Pettay [:smaug] (high review load, please consider other reviewers) 2011-02-28 11:06:27 PST
I'd still like to see either a reasoning for valueAsNumber or it to be
removed from HTML.
Comment 4 Jonas Sicking (:sicking) PTO Until July 5th 2011-03-30 17:11:03 PDT
Comment on attachment 515641 [details] [diff] [review]
Patch v1.1

>+nsHTMLInputElement::GetValueAsNumber(double* aValueAsNumber)
>+{
>+  if (!DoesValueAsNumberApply()) {
>+    *aValueAsNumber = std::numeric_limits<double>::quiet_NaN();
>+    return NS_ERROR_DOM_INVALID_STATE_ERR;
>+  }

XPCOM rules actually dictate that you should not assign to the out parameter here.

r=me with that fixed
Comment 5 Mounir Lamouri (:mounir) 2011-04-13 12:29:35 PDT
(In reply to comment #4)
> Comment on attachment 515641 [details] [diff] [review]
> Patch v1.1
> 
> >+nsHTMLInputElement::GetValueAsNumber(double* aValueAsNumber)
> >+{
> >+  if (!DoesValueAsNumberApply()) {
> >+    *aValueAsNumber = std::numeric_limits<double>::quiet_NaN();
> >+    return NS_ERROR_DOM_INVALID_STATE_ERR;
> >+  }
> 
> XPCOM rules actually dictate that you should not assign to the out parameter
> here.
> 
> r=me with that fixed

Eh, this was actually, wrong: I shouldn't throw an exception when getting a value while valueAsNumber doesn't apply but just returning NaN. This is fixed locally.
Comment 6 Atul Aggarwal 2011-11-05 11:37:56 PDT
Spec bug has been closed as RESOLVED WONTFIX, so I guess patch should be landed into m-c.
Comment 7 Mounir Lamouri (:mounir) 2011-11-07 03:23:47 PST
(In reply to Atul Aggarwal from comment #6)
> Spec bug has been closed as RESOLVED WONTFIX, so I guess patch should be
> landed into m-c.

This will land with the entire <input type='number'> patch queue which is not ready yet.
Comment 8 Mounir Lamouri (:mounir) 2012-07-05 08:57:21 PDT
https://hg.mozilla.org/mozilla-central/rev/340c38628ed5
Comment 9 Holger Jeromin 2012-10-10 07:27:55 PDT
This patch landed too early, as Firefox 16 has no input type=number, but this numberAsValue! Without number support, the result is always NaN, which breaks feature detection.

if (input.valueAsNumber !== undefined){
... input.valueAsNumber;
}else{
... parseInt(input.value, 10);
}
Comment 10 Holger Jeromin 2012-10-11 00:55:59 PDT
Just for the record. The feature detection had to be changed to:
if (input.type === "number" && input.valueAsNumber !== undefined)
the problem is imo still valid.
Comment 11 Florian Scholz [:fscholz] (MDN) 2013-04-27 15:09:36 PDT
See bug 866457 for documentation.

Note You need to log in before you can comment on or make changes to this bug.