BrowserSpy does a good job of pointing out subtle differences between 4.x and 5.0 This example shows that mozilla seeming does not support Javascript versions 1.1 or higher. The offending code always looks like this: <SCRIPT LANGUAGE="JavaScript1.1"> <!-- ver11 = 1; // --> </SCRIPT> <SCRIPT LANGUAGE="JavaScript" TYPE="text/javascript"> <!-- var ver11; (ver11) ? document.writeln("Supported") : document.writeln("Not supported"); // --> </SCRIPT>

The problem here isn't what you think it is. If you remove the "1.1", you still see "Not Supported". The problem has to do with variables disappearing. Normally, it seems that if you have (within one SCRIPT element): number = 1; // number is 1 var number; // number is still 1 If, you define a variable "number" in one SCRIPT element, and then have a "var number" in another SCRIPT element, then the variable defined in the first element doesn't show up in the second (it's undefined), even before the "var number"! (However, without that "var number", things work fine.) I'm not sure from the symptoms whether this is Core JavaScript or DOM (and I do understand the difference at some abstract level). Assigning to JavaScript Engine component and reassigning. I'll attach testcases showing the problem later this evening.

For the record, I'm using Win95 mozilla 1999-12-23-09-M13.

Is this a new bug? If so, then there may be something to fix. I'm guessing not, though; the behavior you describe is how var statements work. Each script tag is logically a separate script, though subsequent tags operate on a a global object that has already had names and properties added by previous script tags. Within a given script or function body, the way var statements work is that the 'var' part of the statement is implicitly promoted to the top of the *script* or function (not top of page; only within the current script tag.) and the associated variable is given the undefined value at that time. Looks like that's overwriting existing values for that name from previous script tags. Then, if there's an initializer ('= 4') associated with the var statement, that executes at the point in the script where the var statement occurs. It's all counter-intuitive, but thanks to the ECMA standards process, it's also all defined behavior. Please go ahead and close this bug, *unless* this behavior is new to Mozilla, in which case there's probably something else going on.

Another thought - I'm not sure if the ECMA-262 spec for JavaScript covers the case where multiple scripts (i.e. script tags) work on the same object. So again, it'd be interesting to know if it's a change from earlier behavior. If it is, it could have something to do with how/when we initialize with the undefined value. If this is existing behavior, then it's probably one of those subtle aspects of behavior that's too dangerous to change.

This is a new bug as compared to 4.x. The first testcase shows "Number is 1" three times in Linux NN 4.7, but "number is 1 / number is undefined / number is undefined" on Mozilla 2000-01-04-09-M13 linux. Changing to All/All from PC/Windows NT.

Also, although I haven't looked at the ECMAScript spec for quite a while (and when I did I wasn't really looking at the parts relevant to this), I find it hard to believe that the contents of the second script element can influence what variables are defined at the beginning of execution of that element.

Well, after reading your explanation in more detail, it's not so hard to believe, but there's still a 4.xP bug here.

Promotion of var statements to the top of the script or function body happens before any execution occurs. Just how this happens could be the issue - looks like this bug could be 'variables are assigned the undefined value rather than inheriting their value from previous script invocations.' Could have something to do with how we're doing scopes. Reassigning to Roger Lawrence.

Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!

Dup of #21618 - Brendan's multi-scripts in a page thing, now fixed. *** This bug has been marked as a duplicate of 21618 ***

Verified dupe of 21618