Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#15270 closed defect (fixed)

dijit.form.DateTextBox: Setting constraints.min causes input to be parsed in regexp strict mode

Reported by: Paul Christopher Owned by: Douglas Hays
Priority: undecided Milestone: 1.8
Component: Dijit - Form Version: 1.7.2
Keywords: Cc:
Blocked By: Blocking:



Setting constraints.min causes the user input to be parsed in "strict mode", i.e. entering just 11 triggers an error message "The value entered is not valid". In contrast a DateTextBox without any constraints shows a different behaviour: Entering 11 or 11/ does not trigger any error message. An error message is only triggered, if wrong/invalid characters are entered.

Steps to reproduce the issue

Run the attachted test case. In textbox one, start to enter a date, e.g. 11/5. Watch the dijit validation message. There are no errors at all.

Now start to enter a date in textbox two. The textbox has constraint.min=new Date(), i.e. you can only enter dates for today or which lie in the future. As soon as you start typing (e.g. 11) the dijit error message pops up: "The value entered is not valid".


Don't know what's the exact reason for this behavior. I have tried to specify constraints.strict=false. However this does not make any difference. I have also overridden the validator so as to see which constraints are passed to the regexp function. However a constraints.strict property / options.strict property does never show up there. So I have no idea why the DateTextBox changes its behavior as soon as a min date is set.

All in all: The error message during typing could be very annoying for users. And some users complaint about this.

Attachments (2)

testDateTextBox.html (1.1 KB) - added by Paul Christopher 10 years ago.
testDateTextBox2.html (2.9 KB) - added by Paul Christopher 10 years ago.

Download all attachments as: .zip

Change History (5)

Changed 10 years ago by Paul Christopher

Attachment: testDateTextBox.html added

comment:1 Changed 10 years ago by Paul Christopher

I'm getting more and more into Dojo, and I think I have found the reason now. The problem is _isValidSubset's call of _isDefinitelyOutOfRange. When entering e.g. just "11", _isDefinitelyOutOfRange already returns true for date objects (whereas it should return false instead?). Therefore by providing a date and time specific function _isDefinitelyOutOfRange in _DateTimeTextBox.js as follows, the above mentioned behavior could be fixed.

Addition for _DateTimeTextBox.js:

_isDefinitelyOutOfRange: function(){
  // If input is not valid, return 'false' so as to not interfere with normal regex parsing 
  if(this._isInvalidDate(this.get('value'))) {
    return false;
  return this.inherited(arguments);

See attached test case "testDateTextBox2.html" for more details.

Changed 10 years ago by Paul Christopher

Attachment: testDateTextBox2.html added

comment:2 Changed 10 years ago by Douglas Hays

Resolution: fixed
Status: newclosed

In [28507]:

Fixes #15270. Change _isDefinitelyOutOfRange to not return true for undefined/null values, and added an automated testcase.

comment:3 Changed 10 years ago by Douglas Hays

Milestone: tbd1.8
Note: See TracTickets for help on using tickets.