Closed
Bug 219308
Opened 21 years ago
Closed 21 years ago
Strict warning over trailing comma in array intiializer due to IE bug
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
VERIFIED
WONTFIX
M1
People
(Reporter: ben_tilly, Assigned: rogerl)
References
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686) Gecko/20030714 Galeon/1.3.7 Debian/1.3.7.20030813-1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686) Gecko/20030714 Galeon/1.3.7 Debian/1.3.7.20030813-1
Trailing commas in various declarations are ignored by Mozilla, but in IE create
null objects and/or parse errors. If this is correct to the standard, it would
be nice to have an "IE compatible mode" so that people developing to Mozilla can
be sure that their code works on IE.
Reproducible: Always
Steps to Reproduce:
1. In the JavaScript console run: top.alert([1,2,3].length)
2. In the JavaScript console run: top.alert({foo: 1, bar: 2,}.bar)
Actual Results:
The first alert alerts 3, the second alerts 2.
Expected Results:
IE 6 thinks that the array has length 4, with the last element being null. IE 6
expects another identifier in the object declaration.
I would like to either see IE 6 compatible behaviour, or a warning in the
JavaScript console about the potential incompatibility.
Comment 1•21 years ago
|
||
> IE 6 thinks that the array has length 4
I think you accidentally dropped a comma from the end of your array.
So below, I will treat the array literal I think you meant: [1,2,3,]
The current spec for ECMAScript (and errata) are available here:
http://www.mozilla.org/js/language/E262-3.pdf
http://www.mozilla.org/js/language/E262-3-errata.html
See the following sections of the spec:
OBJECTS
Ref: Section 11.1.5 Object Initialiser
Trailing commas are not permitted in an object literal. So IE is
correct to throw an error on that. Note this ends JS runtime execution.
The spec allows implementations considerable leeway in handling errors.
We have chosen to let execution continue and throw a warning instead.
See bug 50002, "Strict warning for trailing comma in JS object initializer":
To see this, the Mozilla user must have "Show strict JavaScript warnings"
checked in Edit > Preferences > Debug:
Warning: trailing comma is not legal in ECMA-262 object initializers
Source File: javascript: alert({foo: 1, bar: 2,}.bar)
Line: 1, Column: 23
Source Code: alert({foo: 1, bar: 2,}.bar)
ARRAYS
Ref: Section 11.1.4 Array Initialiser
Here, a trailing comma is permitted:
Syntax
ArrayLiteral :
[ Elisionopt ]
[ ElementList ]
[ ElementList , Elisionopt ]
where the syntax elements are defined this way:
ElementList:
Elisionopt AssignmentExpression
ElementList , Elisionopt AssignmentExpression
Elision:
,
Elision ,
Note an |Elision| is just a series of N commas. According to the spec,
this is how it gets evaluated in the Array Initializer algorithm:
The production Elision : , is evaluated as follows:
1. Return the numeric value 1.
The production Elision : Elision , is evaluated as follows:
1. Evaluate Elision.
2. Return (Result(1)+1).
In other words,
, -----> 1
,, -----> 2
,,, -----> 3
Now, here is the algorithm covering the example above, [1,2,3,]:
The production ArrayLiteral : [ ElementList , Elisionopt ] is evaluated as:
1. Evaluate ElementList.
2. Evaluate Elision; if not present, use the numeric value zero.
3. Call the [[Get]] method of Result(1) with argument "length".
4. Call the [[Put]] method of Result(1) with arguments "length" and
(Result(2)+Result(3)).
5. Return Result(1).
The way I read all of this is:
1. An Elisionopt is not allowed as the final component of an ElementList.
An ElementList must end in an AssignmentExpression.
2. Therefore in the example [1,2,3,] the ElementList is 1,2,3
3. The final comma in [1,2,3,] is not an Elision, but rather the
intermediate comma in the syntax [ElementList , Elisionopt]
4. Therefore we fall into Step 2 of the algorithm:
2. Evaluate Elision; if not present, use the numeric value zero.
5. Therefore in Step 4, when the length of the array is assigned,
we assign (length of ElementList) + 0 ===> 3 + 0 ===> 3.
So I believe that on this question, we are in accordance with the spec,
whereas IE6 is not. I see nothing in the ECMA Errata about this, either.
Comment 2•21 years ago
|
||
cc'ing Brendan, Mike to make sure I haven't erred on any of this.
SUMMARY: trailing commas Moz IE6
javascript: alert({foo: 1, bar: 2}.bar) 2 2
javascript: alert({foo: 1, bar: 2,}.bar) 2 Error <--------- DISCREPANCY
javascript: alert([1,2,3].length) 3 3
javascript: alert([1,2,3,].length) 3 4 <--------- DISCREPANCY
Above, I have stated that the ECMA spec allows the first discrepancy.
The expression is not permitted by ECMA, but the spec allows wide
treatment of such errors, and we've chosen to issue a warning here:
bug 50002, "Strict warning for trailing comma in JS object initializer".
As to the second disrepancy (trailing comma in array initializer),
here there is no syntax error. I have analyzed the ECMA algorithm
for array length, and feel Mozilla is correct here, and IE6 is not.
I am unable to find an Edit->Preferences->Debug menu either on
my copy of Galeon or Mozilla (using a somewhat messed up Debian
system). I can believe that this is a downstream packaging
issue and not a Mozilla issue, in which case I will ask the
Debian folks about this. (Installation of the JavaScript
debugger should cause any associated preference menus to be
available.)
As for the trailing comma in an array, a warning for known
potential discrepancies like that would be on my wishlist.
Updated•21 years ago
|
OS: Linux → All
Summary: Handling of traling commas in declarations differs from IE → Handling of trailing commas in declarations differs from IE
Comment 4•21 years ago
|
||
Comment #2' summary is correct. We allow trailing comma in object initializer
as an extension (see Chapter 16, Errors, for why this is allowed by the spec).
And IE is clearly wrong in returning 4 instead of 3 for [1,2,3,].length, as
Phil's reading of ECMA-262 Edition 3 in comment #1 demonstrates.
Is there a real-world web page that expects other browsers to emulate the IE
array bug? If so, please cite it so we can evangelize. Likewise, if some
real-world page expects Mozilla's extension allowing trialing comma in object
initializer, let's evangelize that site to work in all ECMA-conforming browsers
(it's ok for Mozilla-only JS, e.g., included in XUL files, to use Mozilla's JS
extensions, of course).
Otherwise, this bug is invalid. I'll leave it for Phil to mark it as such if no
evangelism followup appears.
/be
Define "real world".
I am a real developer who had to create a JavaScript component
for a work project. I developed using Mozilla because my
machine is running Linux. After I wrote and debugged my
component locally, I then tested it on IE and was rather
annoyed at having to track down a bunch of nulls and parse
errors.
I doubt that I am the first or last "real" developer to be
bitten in this way. However my component is already fixed, and
no end users will see this.
For random context, I got in the habit of adding trailing
commas when I can because I am primarily a Perl programmer and it
is a convenient habit there. Hence when I was developing in
JavaScript I tested what happened with them, found no errors or
warnings, and proceeded to use the "feature" in autogenerated
code.
Comment 6•21 years ago
|
||
Real-world == on the public internet, where evangelism bugs can be fixed.
That's not to say no hardship arises elsewhere, of course.
In JS1.2, I allowed a trailing comma in an object literal. Alas, the ECMA
working group did not agree to standardize that. ISO C calls a trailing comma
in an enum an error too, I hear (or at least a warning, perhaps an error at the
implementation's discretion). This all sucks, I agree. Sorry I couldn't
prevent MS from prevailing in the working group (this was in '96 or '97).
We already have a strict warning for the trailing comma in object initializer
case, so please use the strict option. We certainly could add a strict warning
for trailing comma in array initializer based on IE's bug, not on ECMA-262 Ed. 3
compliance. I would rather not, at this stage. If the issue arises again, I'd
reconsider.
One problematic, subtle issue here: IE is simply botching the array length for
[1,2,3,], which misleads code to expect (3 < a.length) and (3 in a) to be true.
We will never emulate this bug, so just a warning may not be enough to cause
the few who were misled by IE's bug to fix their code -- but it may bug the heck
out of people who (based on righteous Perl or trad-C experience) want to put a
trailing , in array initializers.
In other words, if you want to use trailing commas as in C or Perl initializers,
do you really expect them to make a "hole" at the end of the array? I think
not. You won't get such a length off-by-1 in C or Perl.
But you tell me: did you want length to be 4 in the example, or did you only
want to be able to write a trailing comma, and have length be 3?
/be
*** This bug has been marked as a duplicate of 67279 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
Comment 8•21 years ago
|
||
I don't feel this bug is a duplicate of bug 67279; it is more general.
Therefore reopening this one before resolving it.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Target Milestone: --- → M1
I wanted to write a trailing comma and have the length be 3.
My workaround was to filter nulls out of the resulting array to test what I had.
Since the test data had a lot of them, and the arrays were used in one place,
that was easy enough for me to do. (And I hopefully won't make the mistake again.)
Comment 10•21 years ago
|
||
Ok, pending another report of someone else misled by IE, I'm going to mark this
bug WONTFIX after changing the summary to say what is being WONTFIXed.
/be
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → WONTFIX
Summary: Handling of trailing commas in declarations differs from IE → Strict warning over trailing comma in array intiializer due to IE bug
Comment 12•21 years ago
|
||
*** Bug 237579 has been marked as a duplicate of this bug. ***
Comment 13•18 years ago
|
||
*** Bug 356131 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•