Closed Bug 1010158 Opened 10 years ago Closed 10 years ago

Browser not accepting fractional or decimal numbers in number field in forms. Only accepting integers when used in number field.

Categories

(Core :: Layout: Form Controls, defect)

31 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: sea, Unassigned)

References

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20140429 Firefox/24.0 Iceweasel/24.5.0 (Nightly/Aurora)
Build ID: 20140429161455

Steps to reproduce:

Used a statement like this in my form;
<input type=number size=4 maxlength=4 name=qty1>


Actual results:

Before I could even leave the feild box, an immediate red box outlined the number stating I had to use the closest number to the next integer.  Would not allow a number like 4.22. Would only accept either 4 or 5 as the input.



Expected results:

It should have taken the real number.  It works fine in Firefox and previously to all other Seamonkey versions.  Running on Debian Linux stable version Debian 3.2.57-3 x86_64 kernel.
> It works fine in Firefox

What version of FF?
In FF 29.0.1, I see just what you describe (the red outline).

I'll also note that the dialog box displays differently depending on the browser version being used.  (IOW something changed between Gecko 28 & 29 affecting the fields display & input.)
No, it's the Firefox type verion called Iceweasel, that came with the recent default Debian OS install.  It's version 24.5.0.  Yeah, the size of my field input got much larger in size.  So the nice looking way the form used to appear for that field input box is causing a wrap on that line now as well. I can live with the appearance issue, but it only taking an integer doesn't work for my app. The entire form is an accounting web application that needs the extra decimals to make an accurate calculation.
But version of Iceweasel is working fine.  It's in the Seamonkey version I'm having the issue with.
Notice what happens here if you change from (a browser Gecko) 28 to 29: http://www.w3schools.com/html/tryit.asp?filename=tryhtml5_form_number_adv

This could be the reason?  Bug 344616 - Implement <input type="number">

In any case, seems to be Core rather then SeaMonkey.
And I'd assume when Iceweasel gets to a Gecko version 29, you'll run into the same situation there.
So, the specs state that it is supposed to be a floating-point number, but then current releases after bug 344616 accept only integers by default. The reasoning is given in

(Quoting Mounir Lamouri (:mounir) from bug 344616 comment #12)
> (In reply to bug 344616 comment #11)
> > If number is a float or double and you can type in fx, 3.14 how can I limit it
> > only to integers? should'nt their be a attribute or something for this behavior
> > or i'm I missing something in the standard?
> 
> By default <input type='number'> should only accept [integers]. You can use the
> step attribute to define which values are accepted. By default step=1. If
> you set <input type='number' step='0.01'>, 3.14 would be a valid value, as 3
> but not 3.141.
> If <input type='number'> has an invalid value, the form wouldn't be
> submittable. It's up to the browser UI to make impossible to the user to set
> an invalid value.

So, in essences, step="1" is the default unless you explicitly set it. Something like

   <form><input type=number size=4 maxlength=4 name=qty1 step=0.00000001></form>

lets me enter fractional numbers as intended, but the up/down arrows are behaving rather odd and give me 1E-8 increments (not unexpectedly). Thus, I'm wondering why - if no step is explicitly defined - numbers are restricted to integers even if typed in directly. IMO, step (for the dials) and allowable value precision (when typed in) should be separated, unless the standard says otherwise.
Blocks: 344616
Component: General → Layout: Form Controls
Product: SeaMonkey → Core
Summary: Seamonkey - Browser not accepting fractional or decimal numbers in number field in forms. Only accepting integers when used in number field. → Browser not accepting fractional or decimal numbers in number field in forms. Only accepting integers when used in number field.
Version: SeaMonkey 2.6 Branch → 31 Branch
For comparison, XUL provides the attributes necessary to distinguish these cases:

   <textbox id="totalOpenTime" type="number" decimalplaces="1" increment="0.5" .../>

(from bug 856451 attachment 735627 [details] [diff] [review]) creates a fractional textbox with dials going in +/- 0.5 steps but allowing you to enter anything with 1 decimal place; e.g., you can enter 3.2 and the dials will switch to 3.7 or 2.7 next with the given increment. So, the HTML "step" attribute should match "increment" but is there an equivalent to "decimalplaces" defined in the standard?
From http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#number-state-(type=number) "The default step is 1". If you want none integer values you need to specify an appropriate "step" attribute. ("any" is a valid value.)
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
Ok, step="any" resolves the issue for me with sea's code and SM 2.28a2 on Windows 7 (the dials still go +/-1 but I can enter arbitrary floating-point values manually without any restrictions in precision).
My bug submission was only regarding Seamonkey being used on a Debian OS Desktop.
(In reply to rsx11m from comment #8)
> Ok, step="any" resolves the issue for me with sea's code and SM 2.28a2 on
> Windows 7 (the dials still go +/-1 but I can enter arbitrary floating-point
> values manually without any restrictions in precision).

The dials will use 1 as the step value if step="any", or the value that you set step to otherwise. So if you set step="0.1" the dials will increment/decrement by 0.1.

(In reply to sea@dcllabs.net from comment #9)
> My bug submission was only regarding Seamonkey being used on a Debian OS
> Desktop.

It should be the same on all products and platforms using gecko 29 and greater.
You need to log in before you can comment on or make changes to this bug.