Closed Bug 106181 Opened 23 years ago Closed 23 years ago

Javascript valid date checking problem on Chase Online

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla0.9.6

People

(Reporter: vance, Assigned: jst)

References

()

Details

(Whiteboard: [HAVE FIX])

Attachments

(5 files)

Go through the setup account at www.chase.com/logon. When you get to the part to add accounts there is a page https://chaseonline.chase.com/chaseonline/authenticate/sso_authen_ques.jsp that asks you questions to authenticate your account. One of these is your birthdate. Valid dates are not accepted, 03/23/1962. A pop-up window that says: "Error Message AA009: The date you entered is not valid. Please enter a valid date" appears. The error is triggered by javascript code. I tried the same page with Netscape 4.78 on Mac and it worked fine.
Thanks for posting the exact URL. With this I was able to see the problem for myself (just entered bogus information except for the date). The good news (for me) is that I could also reproduce this problem on my Linux system (running M0.9.5 too), so its not an OpenVMS specific problem. Changing O/S from OpenVMS to Linux to make sure this bug gets the visibility it deserves. Also confirming the bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: OpenVMS → Linux
Hardware: DEC → All
Confirming bug on WinNT also. OS : Linux --> All.
Assignee: rogerl → khanson
OS: Linux → All
Reduced testcase #1 fails Reduced testcase #2 succeeds The only difference between the two files is this: ---------------- Reduced testcase #1 ----------------------- var daysInMonth = makeArray(13); daysInMonth[1] = 31; daysInMonth[2] = 29; daysInMonth[3] = 31; daysInMonth[4] = 30; daysInMonth[5] = 31; daysInMonth[6] = 30; daysInMonth[7] = 31; daysInMonth[8] = 31; daysInMonth[9] = 30; daysInMonth[10] = 31; daysInMonth[11] = 30; daysInMonth[12] = 31; function makeArray(n) { for (var i = 1; i <= n; i++) { this[i] = 0 } return this } ------------------------------------------------------------- ---------------- Reduced testcase #2 ----------------------- var daysInMonth = [null,31,29,31,30,31,30,31,31,30,31,30,31]; -------------------------------------------------------------
Reduced testcase #1 fails Reduced testcase #3 succeeds The only difference between the two files is this: ---------------- Reduced testcase #1 ----------------------- var daysInMonth = makeArray(13); ------------------------------------------------------------- ---------------- Reduced testcase #3 ----------------------- var daysInMonth = new makeArray(13); -------------------------------------------------------------
The problem is the 'return this' line in the function makeArray() function makeArray(n) { for (var i = 1; i <= n; i++) { this[i] = 0 } return this } If you invoke such a function without using the 'new' keyword, 'this' will evaluate to the global JavaScript object, NOT an instance of a 'makeArray' object as the site authors might intend. In the DOM, the global object is precisely the window object. So the site authors, whether they realize it or not, are doing: window[1] = 31; window[2] = 29; window[3] = 31; etc. This seems to work in NN4.7 and IE4.7, and it works with the global object in the standalone JS shell. But for some reason it doesn't work in Mozilla using trunk binary 20011016xx. Just try this javascript:URL in all three browsers: javascript: window[1]=31; alert(window[1]); or javascript: this[1]=31; alert(this[1]); In NN4.7 and IE4.7, you get '31'. In Mozilla you get 'null'.
SUMMARIZING The site authors use the 'this' keyword in their makeArray() function, but then invoke the function without using the 'new' keyword: var daysInMonth = makeArray(13); Therefore daysInMonth === the window object, so when they do daysInMonth[1] = 31; they are really doing window[1] = 31; which fails in Mozilla (silently). We end up with daysInMonth[1] === null When they validate the date of birth for a customer, they do the following check in the function isDate(): /* * Make sure that the day integer is not greater than * the total number of days in the given month. */ if (intDay > daysInMonth[intMonth]) return false; But because of the issue above, this is really checking if (intDay > null) return false; which always returns false for positive values of intDay. Hence the date validation fails in Mozilla...
Reassigning to the DOM, as this sort of assignment to the global object is succeeding in the standalone JS shell: this[1] = 31; It does not succeed with the global DOM object in Mozilla. It does succeed with the global DOM object in NN4.7, IE4.7. Not sure if this correct in the new DOM or not. If the Mozilla DOM is acting correctly, then we have to reassign this bug to Tech Evangelism. In that case, the line of code that needs changing is indicated above: change var daysInMonth = makeArray(13); to var daysInMonth = new makeArray(13);
Assignee: khanson → jst
Component: Javascript Engine → DOM Level 0
QA Contact: pschwartau → amar
Attached patch Proposed fix.Splinter Review
The problem is that whenever a numeric property is requested from a window we return either the n:th frame, or null if there is no n:th frame. Trivial fix. Jband, sr=?
Status: NEW → ASSIGNED
Whiteboard: [HAVE FIX]
Target Milestone: --- → mozilla0.9.6
Comment on attachment 55013 [details] [diff] [review] Proposed fix. r=jag
Attachment #55013 - Flags: review+
jband, nm Fix checked in, sr=rpotts@netscape.com
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
all the three attached testcases succeds in the javascript date validation. Marking verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: