User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.5 Safari/605.1.15

Steps to reproduce:

On all older versions of Firefox (and other Browsers) this code:
<input type="number" step="0.1" value="10.7" />
results in a text fild with the value "10,7" (not the comma) on systems where commas are used as decimal separator (like german systems).

But now in version 74, the first code results in a field with the value "10.7" which is not formatted correctly with the system settings.

Hmm, so I think this is a misunderstanding of mine when looking at the interop state of this from bug 981248, I think.

In Gecko, before that change, data:text/html,<input type="number" step="0.1" value="10.7" lang="de"> would show the comma, but not in other browsers. So I aligned Firefox with the other browsers.

But it seems other browsers may have been following the lang of the browser installation, instead of the lang specified by the page, ugh...

We clearly need to do something about this, I'll take a look.

Safari and Chrome shows the comma correcty (browser and System are set to German).

(In reply to Gabriel Gritsch from comment #2)

Safari and Chrome shows the comma correcty (browser and System are set to German).

Right, but that's the key difference. On an English build (like the ones I was testing with) they wouldn't show the comma for the lang=de example.

This is what confused me.

Yes but Firefox does NOT show the command on a German System with German Firefox and lang="de".
I had to downgrade all Firefox installations to FF ESR (with --allow-downgrade) - I hop this change/bug does not find its way to the ESR.

command -> comma

Sure, I agree, thus the "we need to do something about this" :)

Thanks for reporting the bug.

This restores our previous behavior with the new <input type=number>
implementation (see the changes in test_input_number_l10n.html, which undoes the
changes of the regressing bug), and adds a test that shows that we display the
localized value properly.

[Tracking Requested - why for this release]: Regression in 74 with a fair amount of duplicates, which would be nice to not ship in 75.

Comment on attachment 9133286 [details]
Bug 1622221 - Rework number input localization. r=jwatt

Beta/Release Uplift Approval Request

• User impact if declined: comment 0 and dupes
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: see comment 0, and all the duplicates
• List of other uplifts needed: None
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): I don't think it's too risky, and the patch is relatively straight-forward, but it's definitely non-trivial code.

The patch is very self-contained to the localized-input-number case, though, so I think it's ok to uplift. Alternative is to keep shipping our current behavior for one more release, but given the amount of dupes that's probably not fine.

• String changes made/needed: none

https://hg.mozilla.org/mozilla-central/rev/07fc10be600e

Comment on attachment 9133286 [details]
Bug 1622221 - Rework number input localization. r=jwatt

fix for regression in 74 with many dupes, let's risk it for 75.0b8

Reproduced with the testcase from comment 0 and the duplicates using Firefox 75 beta 7 under Win 10 64-bit.
Verified as fixed on latest Nightly 76.0a1 2020-03-23 under Win 10 64-bit, Ubuntu 18 and Mac OS X 10.14.

https://hg.mozilla.org/releases/mozilla-beta/rev/83b0389a4187

Backed out due to conflicts on beta:

https://hg.mozilla.org/releases/mozilla-beta/rev/8733a0977d36597461c3fbda0078976235357cc4

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=mozilla-beta&selectedJob=294514168&revision=1df5479b3198b37ede7eef1ae2a89b7c8cf04019
Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=294514178&repo=mozilla-beta

/builds/worker/workspace/obj-build/dist/include/NumericInputTypes.h:47:30: error: unknown type name 'Decimal'

This is the only diff:

diff --git a/dom/html/input/NumericInputTypes.h b/dom/html/input/NumericInputTypes.h
index fa31f7a36e8b..9b53c3c02f86 100644
--- a/dom/html/input/NumericInputTypes.h
+++ b/dom/html/input/NumericInputTypes.h
@@ -44,7 +44,7 @@ class NumberInputType final : public NumericInputTypeBase {
   nsresult GetValueMissingMessage(nsAString& aMessage) override;
   nsresult GetBadInputMessage(nsAString& aMessage) override;
 
-  bool ConvertNumberToString(Decimal aValue,
+  bool ConvertNumberToString(mozilla::Decimal aValue,
                              nsAString& aResultString) const override;
 
  protected:

https://hg.mozilla.org/releases/mozilla-beta/rev/6cc859a46b3d

Backed out changeset 6cc859a46b3d (Bug 1622221) for reftest failures at overflow-clip-box.html.
https://hg.mozilla.org/releases/mozilla-beta/rev/7919cb77a5d770cfbea165b6f70e7538a78bcb1c

Push with failures:
https://treeherder.mozilla.org/#/jobs?repo=mozilla-beta&selectedJob=294590731&resultStatus=pending%2Crunning%2Csuccess%2Ctestfailed%2Cbusted%2Cexception&revision=6cc859a46b3d254f28aa8f76cf0d89928789e528

Failure log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=294590731&repo=mozilla-beta&lineNumber=13407

This was an issue with the original uplift in comment 18. It contained:

+
+== overflow-clip-box.html overflow-clip-box-ref.html
+!= overflow-clip-box.html overflow-clip-box-notref.html

in the reftest manifest which shouldn't be there (as it's a test for bug 1618260 which is not in beta).

https://hg.mozilla.org/releases/mozilla-beta/rev/86930d74d28b

Verified as fixed using Firefox 75 beta 9 under Win 10 64-bit and Ubuntu 18.04 64-bit.