Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#18367 closed defect (fixed)

Constraint 'places' for range in NumberTextBox regression

Reported by: Lukas Kubasek Owned by: Terence Kent
Priority: undecided Milestone: 1.10.3
Component: Dijit - Form Version: 1.10.2
Keywords: Cc:
Blocked By: Blocking:

Description

The constraint 'places' for range of allowed decimal places does not work correctly.

For an example of {places: '0,4'} works fine with 0,1,2,3 decimal places. For equal or more than 5 places correctly raises a validation error. When a number with exactly 4 (= max. allowed) decimal places is entered, the last digit is truncated after tabbing out and simply disappears from the field.

This issue did not occur in 1.9.1. Seems to be a regression since 1.10.0, present also in 1.10.1 and 1.10.2.

Example code:

<!DOCTYPE html>
<html>
<head>
    <title>NumberTextBox 1.10 'places' constraint issue</title>
    <style type="text/css">
        @import "http://ajax.googleapis.com/ajax/libs/dojo/1.10.2/dijit/themes/claro/claro.css";
        @import "http://ajax.googleapis.com/ajax/libs/dojo/1.10.2/dojo/resources/dojo.css";
    </style>
    <script data-dojo-config="async:true, parseOnLoad: true" src="http://ajax.googleapis.com/ajax/libs/dojo/1.10.2/dojo/dojo.js.uncompressed.js">
    </script>
    <script>
        require(["dojo/parser", "dijit/form/NumberTextBox"]);
    </script>
</head>

<body class="claro">
<label for="textbox">Enter a decimal with 4 decimal points and tab out, the fourth decimal digit disappears:</label>
<input type="text"
       id="textbox"
       data-dojo-type="dijit/form/NumberTextBox"
       required="true"
       data-dojo-props="placeHolder: 'Enter a value',
                        constraints: {places:'0,4', round: '-1'},
                        invalidMessage: 'Value may contain up to 4 decimal places'"/>
<button>Submit</button>
</body>
</html>

Change History (12)

comment:1 Changed 5 years ago by Lukas Kubasek

I have looked further into the source code and it looks like that changes in NumberTextBox? introduced as part of 1.10.0 caused this issue.

The new function getDecimalInfo() loads the default pattern for current locale (which is #,##0.### in my en_GB case). The precision (3 decimal places) given by this default pattern should never be used later since the 'places' constraint definition overrides the decimal precision given by the pattern.

The main issue is then in the filter() function that was changed for 1.10.0 (commit https://github.com/dojo/dijit/commit/f018c601b407592956dd56cd41a5edfe332d55d2 fixing https://bugs.dojotoolkit.org/ticket/17955). This function executes an implicit rounding for some reason. This rounding uses the decimal precision given by the default pattern (3 decimal places) which does not correspond to the places constraint definition set to {0,4}. This change therefore breaks the range based 'places' constraint feature.

Last edited 5 years ago by Lukas Kubasek (previous) (diff)

comment:2 Changed 5 years ago by bill

Component: GeneralDijit - Form
Owner: set to Terence Kent
Status: newassigned

tkent, is this from your #17955 changes?

comment:3 Changed 5 years ago by Terence Kent

@lukas.kubasek

Thanks for the detailed bug report, I'll look into the problem this evening

comment:4 Changed 5 years ago by Terence Kent

@lukas.kubasek

Can you confirm this JS fiddle works for you? It includes an aspect that, if applied to the NumberTextBox?, will patch the issue in the current dojo version.

http://jsfiddle.net/terencekent/r6c0favc/

@bill

I noticed that Lukas is using the 'round' parameter in his example. I haven't seen this before so I googled it and it looks like this is a feature that is intended to be deprecated from your comments in #5612. Is that correct, or should I be careful to respect this parameter as well.

Last edited 5 years ago by Terence Kent (previous) (diff)

comment:5 Changed 5 years ago by bill

@tkent, did you mistype that bug number? #5126 seems unrelated to anything. Unfortunately I don't remember anything about the round parameter (and whether or not we had meant to deprecate it).

comment:6 Changed 5 years ago by Terence Kent

@bill

ha! I did, I meant #5612

comment:7 Changed 5 years ago by bill

I see. Indeed, I deprecated the round parameter so I wouldn't worry about that feature, at least for now.

comment:8 Changed 5 years ago by Lukas Kubasek

@tkent

Thanks very much for the JS fiddle. It works as expected, let me use that aspect as a fix for now.

@tkent/@bill

No worries with the round parameter. It does not seem to be significant and needed at all as I set it to "-1" (= no rounding) anyway.

comment:9 Changed 5 years ago by Lukas Kubasek

@tkent

One more note. I have noticed usage of "." as a hard coded decimal separator in the NumberTextBox? source code. It is working fine for me now (en-uk locale), it may however not work correctly for other locales. I would expect something like bundle.decimalSeparator instead. Am I missing something?

comment:10 Changed 5 years ago by Bill Keese <bill@…>

Resolution: fixed
Status: assignedclosed

In 301927d25a269238e8d1f95baf9961a1215c1896/dijit:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

comment:11 Changed 5 years ago by Bill Keese <bill@…>

In 274e4c66fcc0367dea8673c012e3e60f09cf5b95/dijit:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

comment:12 Changed 5 years ago by bill

Milestone: tbd1.10.3

Thanks for the fix, I checked it in to master and the 1.10 branch.

@lukas.kubasek, as for the hardcoded decimal character in NumberTextBox? source code, IIRC that's because when you specify a pattern in javascript source code it's always in the American (aka javascript) format, regardless of whether the region uses period or comma as the decimal character.

Note: See TracTickets for help on using tickets.