Anton Reporter
	Description • 11 years ago

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/20100101 Firefox/19.0
Build ID: 20130215130331

Steps to reproduce:

I tried to enter a number with a comma in a form, with the type "number".


Actual results:

No value or the value 0 was sent.


Expected results:

The value entered in the form should have been sent.

When I enter a number with a decimal point in stead of a comma, the browser returns "Selecteer een geldige waarde" (Dutch for "Select a valid value")

	Aaron Train [:aaronmt]
	Comment 1 • 11 years ago

Can you try out Nightly (http://nightly.mozilla.org) and report back here if that works out for you? Also, which Android device and keyboard are you using?

	Anton Reporter
	Comment 2 • 11 years ago

Android device = Samsung Galaxy S (GT-I9000)
Android version = 4.0.4 (CyanongenMod 9.1.0-galaxysmtd)
Keyboard = standard keyboard of Cyanogenmod

	Anton Reporter
	Comment 3 • 11 years ago

Great... installed the Nightly version, but when I started Firefox nightly, it crashed because my phone was out of memory. And now I can't even restart my phone. Thanx... :(

	Aaron Train [:aaronmt]
	Comment 4 • 11 years ago

Sorry to hear that. If you can get your phone into a stable state and are able to reproduce on perhaps any newer version channel we'd appreciate if you are able to narrow down some steps to reproduce.

	Anton Reporter
	Comment 5 • 11 years ago

I'm not going to install another nightly version. But you can try it yourself. I made a test form, which echo's the outputs of the form: http://dump.antonboonstra.nl/test-form.php

The input with the type "number" is correctly sent with Firefox for Windows and the standard browser in Android, but not with Firefox 19 for Android (dutch version).

	Martijn Wargers (dead)
	Comment 6 • 11 years ago

I'm using Dutch version of Android on Galaxy Nexus.
With the stock browser, I can enter numers like '123.5' and it gets submitted in the results.
When I enter '123,5', before submission, the text input value is changed into '123' and then gets submitted.

On Fennec trunk, entering '123,5' empties the whole text input and then it gets submitted.
Enter '123.5' gives the 'select a valid value' popup.

	Martijn Wargers (dead)
	Comment 7 • 11 years ago

This might have been changed by bug 765772.

	Mark Finkle (:mfinkle) (use needinfo?)
	Comment 8 • 11 years ago

(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #7)
> This might have been changed by bug 765772.

So this bug seems fixed?

	Martijn Wargers (dead)
	Comment 9 • 11 years ago

No, I meant that this bug might have been caused by that bug.

	Mounir Lamouri (:mounir)
	Comment 10 • 11 years ago

I was expecting the virtual keyboard to allow commas when the locale allow commas. Isn't that the case? Then, we should make sure that the number that the Android code sends to the HTMLInputElement is following the HTML5 specification (ie. it should use a dot (.) instead of a comma).

	Anton Reporter
	Comment 11 • 11 years ago

The stock browser of CM9.1 doesn't even accept a comma if you try to enter it. Only a decimal point which is submitted correctly.

In Firefox you can enter a comma and you can even submit the form, but the submitted value is empty. You can also enter a decimal point, but you can't submit the form, because of the 'select a valid value' pop-up.

	(inactive) Jim Chen [:jchen] [:darchons]
	Comment 12 • 11 years ago

(In reply to Mounir Lamouri (:mounir) from comment #10)
> I was expecting the virtual keyboard to allow commas when the locale allow
> commas. Isn't that the case? Then, we should make sure that the number that
> the Android code sends to the HTMLInputElement is following the HTML5
> specification (ie. it should use a dot (.) instead of a comma).

The stock keyboard on Android allows commas in number mode regardless of locale.

My opinion is that Gecko should parse the user input according to locale into a format that matches the HTML5 spec. Or at least not empty the input when the value is invalid.

Parsing the input in the Android code is more difficult because the Android code does not send the number to Gecko all at once; instead it sends each digit to Gecko as it's received from the keyboard.

	Mounir Lamouri (:mounir)
	Comment 13 • 11 years ago

(In reply to Jim Chen [:jchen :nchen] from comment #12)
> My opinion is that Gecko should parse the user input according to locale
> into a format that matches the HTML5 spec. Or at least not empty the input
> when the value is invalid.

This behaviour would require solving bug 805049.

	Simon Montagu :smontagu
	Comment 17 • 10 years ago

Comment on attachment 8367797 [details] [diff] [review]
part 1 - Add some ICU utils classes and static methods

Review of attachment 8367797 [details] [diff] [review]:
-----------------------------------------------------------------

r=me with a couple of nits fixed:

::: intl/unicharutil/util/ICUUtils.cpp
@@ +80,5 @@
> +
> +  Locale locale;
> +  locale.setToBogus();
> +
> +  NS_LossyConvertUTF16toASCII bcp47code(aBCP47Code);

LossyConvert is fine, because BCP47 codes are guaranteed to be ASCII, but please add a comment to that effect.

@@ +127,5 @@
> +                         ContentLocaleIter& aLocaleIter,
> +                         nsAString& aLocalizedValue)
> +{
> +  UErrorCode status = U_ZERO_ERROR;
> +  Locale locale = aLocaleIter.GetNext();

Please assert here and in ParseNumber that aLocaleIter is uninitialized

	Jonathan Watt [:jwatt] Assignee
	Comment 18 • 10 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/340786b6f4dd
https://hg.mozilla.org/integration/mozilla-inbound/rev/2682af062a4b

Simon, I had a huge headache trying to figure out linker errors on the Linux ASAN machine. Amongst other things I set up an ASAN build on my Mac and couldn't repro, set up and ASAN build on Linux, tried various configs and still couldn't repro, and tried every suggestion the build peers came up with in #build and more. All to no avail. I just couldn't get that machine to link to ICU C++ symbols. Besides this issue, it turns out using the ICU C++ API would break --with-system-icu anyway. For both these reasons I switched from the C++ API to the C API before landing. You may want to take a look oven the commit as landed.

	Jonathan Watt [:jwatt] Assignee
	Comment 19 • 10 years ago

Oh, and I added a pref to allow the l18n people to configure our localized builds to decide whether or not they want <input type=number> to use grouping (thousands) separators.

	Phil Ringnalda (:philor)
	Comment 20 • 10 years ago

https://hg.mozilla.org/mozilla-central/rev/340786b6f4dd
https://hg.mozilla.org/mozilla-central/rev/2682af062a4b

	Jean-Yves Perrier [:teoli]
	Comment 21 • 10 years ago

If I understand well, this allows to type arabic, persian, japanese numbers in <input type=number>. This is a pretty important change and I think it should be relnoted. What's your opinion :jwatt? (Relnote meeting is tomorrow)

	Jonathan Watt [:jwatt] Assignee
	Comment 22 • 10 years ago

This will release at the same time as the support for <input type=number>, so I'd think it should just be mentioned as part of that item in the relnotes.

	Jean-Yves Perrier [:teoli]
	Comment 23 • 10 years ago

:jwatt : seems logical, thx

	Simon Montagu :smontagu
	Comment 24 • 10 years ago

Thanks for the headsup, that should be fine.

	Petruta Horea [:phorea], Desktop QA
	Comment 25 • 10 years ago

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0

On latest Dutch Aurora version (20140305004002) neither comma nor decimal point are allowed in the field (it's highlighted and a message is displayed).

Do I need to make other system changes in order to verify that this bug is fixed? Thank you

	Jonathan Watt [:jwatt] Assignee
	Comment 26 • 10 years ago

petruta, I can't reproduce. Are you seeing this because the number control you're using doesn't have the 'step' attribute set? (What are you using to test?) What if you try this:

data:text/html,<input type=number lang=nl step=any>

	Petruta Horea [:phorea], Desktop QA
	Comment 27 • 10 years ago

Hi Jonathan, sorry for late answer.

I used the link provided in URL (http://dump.antonboonstra.nl/test-form.php) where 'step' attribute is not set.

Using "data:text/html,<input type=number lang=nl step=any>" in the Dutch Aurora version, it seems that "." is replaced by "," and the arrows work as expected.

	Jonathan Watt [:jwatt] Assignee
	Comment 28 • 10 years ago

The default step is 1, so fractional values are not allowed by default. Thus the behavior that you were seeing on that page is as expected.

	Petruta Horea [:phorea], Desktop QA
	Comment 29 • 10 years ago

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0

Verified as fixed on latest Aurora 29.0a2 (20140312004002), in Dutch builds "." is replaced by "," in input type number fields.