#18260 closed defect (fixed)
NumberTextBox is rounding values
| Reported by: | bwa | Owned by: | |
|---|---|---|---|
| Priority: | high | Milestone: | 1.10.1 |
| Component: | Dijit - Form | Version: | 1.10.0 |
| Keywords: | Cc: | cjolif, Terence Kent | |
| Blocked By: | Blocking: |
Description (last modified by )
When migrating form dojo 1.8 to dojo 1.10 our NumberTextBox? is starting to round values.
Our constraints is set as following:
data-dojo-props="constraints:
{
min: 0,
max: 133,
pattern: '##0.##'
},
With dojo 1.8 and 1.9 I can enter a values of 5,88 and have it accepted. When changing to dojo 1.10, the input of 5,88 is rounded up to 6 when focus is lost.
Here's a complete example :
<!DOCTYPE html>
<html>
<head>
<title>Demo page</title>
<style type="text/css">
@import "http://ajax.googleapis.com/ajax/libs/dojo/1.10.0/dijit/themes/tundra/tundra.css";
@import "http://ajax.googleapis.com/ajax/libs/dojo/1.10.0/dojo/resources/dojo.css";
</style>
<script data-dojo-config="async:true, parseOnLoad: true"
src="http://ajax.googleapis.com/ajax/libs/dojo/1.10.0/dojo/dojo.js.uncompressed.js" >
</script>
<script>
require(["dojo/parser", "dijit/form/NumberTextBox"]);
</script>
</head>
<body class="tundra">
<label for="textbox">Integer between 0 and 133:</label>
<input id="textbox" type="text"
data-dojo-type="dijit/form/NumberTextBox"
name= "elevation"
required="true"
value="0"
data-dojo-props="constraints:
{
min: 0,
max: 133,
pattern: '##0.##'
},
invalidMessage:'Please enter a numeric value.',
rangeMessage:'Invalid elevation.'" />
<button>dummy button (tab to here)</button>
</body>
</html>
Change History (14)
comment:1 Changed 8 years ago by
| Cc: | cjolif added |
|---|
comment:3 Changed 8 years ago by
I think the bug is in NumberTextBox? when this was introduced ( sometimes after 1.9.0) :
// A private helper function to determine decimal information
// Returns an object with "sep" and "places" properties
var getDecimalInfo = function(constraints){
...
...
_setConstraintsAttr: function(/*Object*/ constraints){
...
...
----- here ---->>>> // this resolves to 0 with a pattern of pattern: '##0.##'
this._decimalInfo = getDecimalInfo(constraints);
},
then it's rounded by this._decimalInfo.places which is now 0, it should be 2 ?
filter: function(/*Number*/ value){
// summary:
// This is called with both the display value (string), and the actual value (a number).
// When called with the actual value it does corrections so that '' etc. are represented as NaN.
// Otherwise it dispatches to the superclass's filter() method.
//
// See `dijit/form/TextBox.filter()` for more details.
if(value == null /* or undefined */ || typeof value == "string" && value ==''){
return NaN;
}else if(typeof value == "number" && !isNaN(value) && value != 0){
value = number.round(value, this._decimalInfo.places);
}
return this.inherited(arguments, [value]);
},
comment:4 Changed 8 years ago by
| Cc: | Terence Kent added |
|---|
Hi Terence, the code he's mentioning is from you, for #17955, can you work on this ticket? (I haven't analyzed it in detail, so it's possible it's a user error, but it sounds like a regression.)
comment:5 Changed 8 years ago by
| Description: | modified (diff) |
|---|
comment:6 Changed 8 years ago by
More investigating shows that bundle.decimal is ',' for no-nb (norway), but it looks like the next line of code is using ',' for splitting the pattern, but the decimal split character is '.'
see http://www.unicode.org/reports/tr35/tr35-numbers.html#Special_Pattern_Characters
places = placesSpecified ? constraints.places : (pattern.indexOf(bundle.decimal) != -1 ? pattern.split(bundle.decimal)[1].replace(/[#0]/g, "").length : 0);
If I change bundle.decimal to '.', the function works.
comment:7 Changed 8 years ago by
| Milestone: | tbd → 1.10.1 |
|---|---|
| Priority: | undecided → high |
comment:8 Changed 8 years ago by
Yes the problem is clearly in the new code in getDecimalInfo where it seems the pattern code is trying to leverage bundle.decimal where it should not as the pattern format is independent of the locale.
comment:9 Changed 8 years ago by
@bwa
Thanks for the investigation, that's certainly the issue
@bill
I'll get a patch and jsfiddle in for this shortly
comment:10 Changed 8 years ago by
@bwa
I'm running the regression tests with the patch now, can you confirm that the drop-in patch in this jsfiddle works for you?
comment:11 Changed 8 years ago by
@tkent Yes, the jsfiddle looks to be the right solution and worked as expected. It also did round when 3 decimals was entered.
So it looks like we have nailed it.
Thanks.
comment:12 Changed 8 years ago by
We are building 1.10.1 tomorrow, would be good to have the fix in before then.
comment:13 Changed 8 years ago by
| Owner: | set to Bill Keese <[email protected]…> |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
This is very urgent for our company. We have decided to migrate from 1.8 til 1.10, and most works fine, but this is not, and causing a big trouble for us, and the input is altered to something wrong. We require 2 digits in our input fields, but now it's rouded up/down to nearest integer.