229180 - Hang when dropdown is used because script is used as js1.2 and isn't correct js1.2

Status: RESOLVED INVALID

(Tech Evangelism Graveyard :: English US, defect)

Description

[H]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

Mozilla 1.6a and Firbird 0.7 crash when the arrival "day of month" dropdown is
selected. Works fine in IE 6.0.

Reproducible: Always

Steps to Reproduce:
1. Go to http://budgetkeywest.com/reservations.htm
2. Attempt to change the arrival "day of month"
3.

Actual Results:  
Mozilla/ Firebird starts using 100% CPU and needs to terminated

Expected Results:  
Should allow selection of date

This may be related to the javascript being used for the dropdown. Am not sure.

Comment 1

[Christopher Archer]

Confirmed on Win2K SP3, Mozilla build 2003121808

Mozilla locks up (~100% CPU) and must kill the process. No talkback generated

Comment 2

[Rene Pronk]

Confirming under Win2000 SP4.
Mozilla build 2003121408 and Firebird 20031203

Comment 3

[Oliver Klee]

Seeing this on a 20031220 Linux CVS build as well. -> OS=All

Comment 4

[Felix Miata]

Top shows 97% CPU on SuSE with Seamonkey 2003122208 mozilla.org tar.gz. Doesn't
matter whether viewport scrolled to drop up or drop down. Must be killed to use
again.

Comment 5

[Frank Wein [:mcsmurf]]

Stacktrace to the point where it hangs:
JS3250! PRMJ_FormatTime + 678 bytes
JS3250! PRMJ_DSTOffset + 148 bytes
JS3250! js_GetErrorMessage + 3201 bytes
JS3250! js_GetErrorMessage + 3060 bytes
JS3250! js_InitDateClass + 1582 bytes
JS3250! js_Invoke + 2557 bytes
JS3250! js_Interpret + 28523 bytes
JS3250! js_Invoke + 2653 bytes
JS3250! js_Interpret + 43406 bytes
JS3250! js_Invoke + 2653 bytes
JS3250! js_InternalInvoke + 225 bytes
JS3250! JS_CallFunctionValue + 34 bytes
JSDOM! nsJSContext::CallEventHandler(void *,void *,unsigned int,void *,int *) +
367 bytes
JSDOM! nsJSEventListener::HandleEvent(class nsIDOMEvent *) + 1859 bytes
GKLAYOUT! nsEventListenerManager::HandleEventSubType(struct nsListenerStruct
*,class nsIDOMEvent *,class nsIDOMEventTarget *,unsigned int,unsigned int) + 690
bytes
GKLAYOUT! nsEventListenerManager::HandleEvent(class nsIPresContext *,struct
nsEvent *,class nsIDOMEvent * *,class nsIDOMEventTarget *,unsigned int,enum
nsEventStatus *) + 749 bytes
GKLAYOUT! nsGenericElement::HandleDOMEvent(class nsIPresContext *,struct nsEvent
*,class nsIDOMEvent * *,unsigned int,enum nsEventStatus *) + 1757 bytes
GKLAYOUT! nsHTMLSelectElement::HandleDOMEvent(class nsIPresContext *,struct
nsEvent *,class nsIDOMEvent * *,unsigned int,enum nsEventStatus *) + 247 bytes
GKLAYOUT! PresShell::HandleEventInternal(struct nsEvent *,class nsIView
*,unsigned int,enum nsEventStatus *) + 619 bytes
GKLAYOUT! PresShell::HandleEventWithTarget(struct nsEvent *,class nsIFrame
*,class nsIContent *,unsigned int,enum nsEventStatus *) + 42 bytes
GKLAYOUT! nsListControlFrame::FireOnChange(void) + 125 bytes
GKLAYOUT! nsListControlFrame::ComboboxFinish(int) + 151 bytes
GKLAYOUT! nsListControlFrame::MouseUp(class nsIDOMEvent *) + 684 bytes
GKLAYOUT! nsListEventListener::MouseUp(class nsIDOMEvent *) + 65 bytes

I recognized the function PRMJ_FormatTime goes from
JS3250! PRMJ_FormatTime + 399 bytes to
JS3250! PRMJ_FormatTime + 715 bytes
and then jumps back and loops again

Comment 6

[Frank Wein [:mcsmurf]]

It seems the JS loops very often, so i'm not sure if this bug isn't caused by
the loop (and Mozilla doesn't detect the loop, when trying around i only got a
loop alert in 1 of 10 cases and only when JS debugger was open).

Comment 7

[David :Bienvenu]

I also see this at www.elencantohotel.com, under reserverations (it must use the
same underyling reservation system).

This works fine on IE, which makes me think the js isn't looping on IE.

Comment 8

[Brendan Eich [:brendan]]

Where's the loop?  Is it really in the bowels of prmjtime.c, or does control
unwind all the way back to scripted code, and repeat?  I.e., if you wait long
enough, do you eventually see the "A script on this page is causing mozilla to
run slowly..." dialog?

A reduced testcase would be cool.

/be

Comment 9

[David :Bienvenu]

yes, sorry, the loop is in interpreted js - control returns to the js. However,
I haven't seen the "a script on this page..." dialog. I think the html on the
page calls a checkDates() method, and that's what's hanging. But I don't see the
source for that js method and I don't know how to get to it...I could try the js
debugger, I guess.

Comment 10

[David :Bienvenu]

here's the js code:

http://booker.hotelfactory.com/date_functions.js


In particular, I think fixDate is hanging (though it's just a guess)

function fixDate (f, id, combo) {
// Fixes invalid dates like 31 Apr 2003 or 29 Feb 2003.
  if (combo) {
    // grabs the form values and sets the form elements later
    var day = f.elements[id + 'DD'].value;
    var temp = f.elements[id + 'YM'].value.split(":");
    var yr = temp[0];
    var mon = temp[1];
    while (!validDate(yr, mon, day)) {  // valid date yet?
      day--;  // no?  move back one day
    }
    if (day.length < 2 && day < 10) {
      day = '0' . day;
    }
    temp = Array(yr, mon);
    f.elements[id + 'DD'].value = day;
    f.elements[id + 'YM'].value = temp.join(":");
  } else {
    // works directly on the form elements
    var day = f.elements[id + 'DD'];
    var mon = f.elements[id + 'MM'];
    var yr = f.elements[id + 'YY'];
    while (!validDate(yr.value, mon.value, day.value)) {  // valid date yet?
      day.value--;  // no?  move back one day
    }
  }
}


function validDate (yr, mon, day) {
// If the year, month and day passed in
// make a valid date, then return true
// otherwise return false.
  mon--; // month is zero based
  var test = new Date (yr, mon, day);
  return (yr  == test.getFullYear() &&
          mon == test.getMonth() &&
          day   == test.getDate()
         ) ? true : false;
}

Comment 11

[Andrew Schultz]

yes, the fixDate/validDate combo is what causes the problem.  It took a few
minutes for Mozilla to notice the evil script and allow the user to stop it.  If
I replace the validDate function with a simple "return false" is takes 6 seconds
for Mozilla to interruprt the script.

Comment 12

[timeless]

since the script does go out to dom this isn't a jseng bug

Comment 13

[David :Bienvenu]

I'm not at all sure I buy the timeless logic there. But it certainly could be a
dom bug. The odd thing is that the date that's used is a valid date, so the js
code should be quick.

Comment 14

[timeless]

Well, this is what i used in xpcshell based on comment 10:

js> function validDate (yr, mon, day) {
// If the year, month and day passed in
// make a valid date, then return true
// otherwise return false.
  mon--; // month is zero based
  var test = new Date (yr, mon, day);
  return (yr  == test.getFullYear() &&
          mon == test.getMonth() &&
          day   == test.getDate()
         ) ? true : false;
}
js> validDate(1000,1,1)
true
js> validDate(1,1,1)
false
js> yr={value:1}
[object Object]
js> mon={value:1}
[object Object]
js> day={value:27}
[object Object]
js>     while (!validDate(yr.value, mon.value, day.value)) {  // valid date yet?
      day.value--;  // no?  move back one day
    }


I had to ^C it, because it was guaranteed never to finish.

Here's what actually turned up in jsdebugger:
function validDate(yr=string:"2004", mon=string:"01", day:integer:-6113) in
<https://booker.hotelfactory.com/date_functions.js> line 22

Note that the integer is never (well, in reasonable time) going to reach a happy
valid state.

One frame up:
 -  267     while (!validDate(yr, mon, day)) {  // valid date yet?
 -  268       day--;  // no?  move back one day
    269     }

Full stack trace:
#0: function validDate(yr=string:"2004", mon=string:"01", day=integer:-6113) in
<https://booker.hotelfactory.com/date_functions.js> line 22
#1: function fixDate(f=HTMLFormElement:{0}, id=string:"INDATE_",
combo=integer:1) in <https://booker.hotelfactory.com/date_functions.js> line 267
#2: function checkDates(e=HTMLSelectElement:{1}, pair=integer:1, swap=void:void)
in <https://booker.hotelfactory.com/date_functions.js> line 302

I'm still /slowly/ tracing through this thing trying to figure out how it
reached this problem state. The code is generally broken. You should not write a
loop like this, as it's very easy for the input to be invalid enough that it
will loop forever.

Comment 15

[timeless]

Ok, thanks to venkman I finally understand what's going on.

Here's the validDate function that spidermonkey is actually playing with:
     function validDate(yr, mon, day) {
 -  3         mon--;
 -  4         var test = new Date(yr, mon, day);
 B  5         return (yr === test.getFullYear() &&
 -  6             mon === test.getMonth() && day === test.getDate()) ? true : false;
    7     }

Note that it's using === instead of ==

yr is a string, but getFullYear is a number. So this test always fails.

Note the relevant html:
<SCRIPT LANGUAGE="JavaScript1.2" SRC="../glossary.js"></SCRIPT>
<SCRIPT LANGUAGE="JavaScript1.2" SRC="../uzback.js"></SCRIPT>
<SCRIPT LANGUAGE="JavaScript1.2" SRC="../date_functions.js"></SCRIPT>
<SCRIPT LANGUAGE="JavaScript1.2">...

In js1.2 == is the stronger equality test. see
http://infodoc.unicaen.fr/docs/javascript/js1_2/operator.htm#1005542
http://infodoc.unicaen.fr/docs/javascript/js13.html#strict

Two options:
1. leave this bug in the dom wasteland for not quickly detecting the slow script
(this is a dupe candidate)
2. move this bug to tech evangelism and explain to the site author how to use
js1.2 (there are various ways to deal with the problem...)

Comment 16

[Hallvord R. M. Steen [:hallvors]]

Problem not found