Custom print margin value don't use locale's decimal separator
Categories
(Toolkit :: Printing, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox113 | --- | fixed |
People
(Reporter: kjell, Assigned: dwalker, Mentored)
References
Details
(Whiteboard: [lang=js])
Attachments
(4 files, 1 obsolete file)
Screen dump showing mix of decimal separators.
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:86.0) Gecko/20100101 Firefox/86.0
Steps to reproduce:
Tried in Swedish locale on Windows 10 to set custom print margins.
Actual results:
The existing values are (mostly?) displayed localized with comma as decimal separator, but I can't type a comma when I try to edit the values. I can type a point as decimal separator and it seems to be correctly interpreted.
I wrote "(mostly?)" above, because I currently see point in one field but comma in the other three.
Also, the margin setting seems to onyl support inches.
Expected results:
I should be able to type comma as a decimal separator in my locale, but not point.
The existing values should always be displayed using the locale's decimal separator.
It should support the locale's standard unit, in my case metric, usually cm or mm for this type of setting.
|
||
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Printing: Setup' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
|
||
Comment 2•3 years ago
•
|
||
In Nightly (Bug 1682162) the margins drop-down now supports millimeters. However the other issue of one number input apparently using a different number formatting is extremely strange.
|
||
Comment 3•3 years ago
|
||
Actual results:
I should be able to type comma as a decimal separator in my locale, but not point.The existing values should always be displayed using the locale's decimal separator.
It should support the locale's standard unit, in my case metric, usually cm or mm for this type of setting.
I'm updating the title of the bug to focus on the decimal separator issue.
The unit we choose for the margins is not locale-dependent, but determined by the units used by the selected printer.
But the number inputs for assigning custom margin value should definitely use locale-appropriate decimal separators - and it should be consistent across each of the margin inputs. :kjell, can you still reproduce this with the described actual output from comment #0 in today's Nightly?
(In reply to Sam Foster [:sfoster] (he/him) from comment #3)
But the number inputs for assigning custom margin value should definitely use locale-appropriate decimal separators - and it should be consistent across each of the margin inputs. :kjell, can you still reproduce this with the described actual output from comment #0 in today's Nightly?
Just tested Nightly. It seems to display using comma, but I can only enter values with point. When I type in a value with a decimal point, it seems to be correclty interpreted, and it stays displayed wit a dot as long as I have the print/preview open. If I close it and reopen it, the first time it had changed all the values back to decimal comma. But then I tested editing some values by replacing the comma with a dot, and some by leaving the comma in place but changing the digits. After that, when I closed the print/preview and brought it up again, it showed a mixture of decimal separators. This situation remained after closing Firefox Nightly and starting it again. See new dump.
|
||
Comment 6•3 years ago
|
||
We have some regexes [0] that try to clean up the inputs on these so it's just numbers and .s. That should support commas too
|
||
Comment 7•3 years ago
|
||
(In reply to Mark Striemer [:mstriemer] from comment #6)
We have some regexes [0] that try to clean up the inputs on these so it's just numbers and
.s. That should support commas too
Maybe poke folks in the Intl team?
https://chat.mozilla.org/#/room/#i18n:mozilla.org
I hope there are better ways to address this (or, at least, solutions that scale across all locales).
(In reply to Mark Striemer [:mstriemer] from comment #6)
We have some regexes [0] that try to clean up the inputs on these so it's just numbers and
.s. That should support commas too
A more appropriate way to validate these inputs would probably be to try a string-to-float conversion with the user's locale and mark as invalid if it fails. If a cleanup is supposed to be used in any way I'd suggest to wimply trim away leading and trailing whitespace and nothing else. If a user enters any other esoteric stuff, that's their problem i.m.h.o.
A more appropriate way to validate these inputs would probably be to try a string-to-float conversion with the user's locale and mark as invalid if it fails. If a cleanup is supposed to be used in any way I'd suggest to wimply trim away leading and trailing whitespace and nothing else. If a user enters any other esoteric stuff, that's their problem i.m.h.o.
Correction: Try user's locale first, then some default locale, probably en-us or some other en-**. If both fail, mark as invalid.
|
Assignee | |
Updated•1 year ago
|
|
|
Assignee | |
Comment 10•1 year ago
|
||
|
|
Assignee | |
Comment 11•1 year ago
|
||
I've submitted a change to remove the input-blocking behavior that triggers on keypress and paste. The numeric fields in print settings will still use the browser's built-in number validation which is locale-aware, and will now just highlight the field and show an error when an invalid value is entered.
|
|
Assignee | |
Comment 12•1 year ago
|
||
proposed UI change introduced by D162161
|
|
Assignee | |
Comment 13•1 year ago
|
||
|
||
Updated•1 year ago
|
|
|
Assignee | |
Comment 14•1 year ago
|
||
After some discussion with mstriemer, he explained that the existing manual validation exists primarily to prevent whitespace from polluting the input. This otherwise results in a validation error with a non-obvious remediation since the whitespace is invisible.
I've submitted a new patch that performs some manual input handling exclusively to prevent this whitespace pollution, and otherwise leaves user input untouched. This will remove the inconsistencies with locale and decimal separators.
|
||
Comment 15•1 year ago
|
||
Pushed by dwalker@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b82cadb1eb61 simplify print margin validation to only trim whitespace.r=mstriemer
|
||
Comment 16•1 year ago
|
||
| bugherder | ||
Description
•