321079 - Firefox allows "class" as a valid variable name in JavaScript

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Eric Seidel]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/417.9 (KHTML, like Gecko) Safari/417.8
Build Identifier: Firefox 1.5

FireFox allows "class" as a valid variable name in JavaScript

Yet this is disallowed by the ecma spec, and IE, as well as Safari and probably other browsers.

Reproducible: Always

Steps to Reproduce:
Load the URL.  If you see "Success" it's still broken.  (I wrote that test case thinking that FireFox's behavior was correct and Safari was wrong at first.)

Comment 1

[Eric Seidel]

The original Safari "bug":
http://bugzilla.opendarwin.org/show_bug.cgi?id=6179

Comment 2

[Aiko]

Attachment: Script to determine reserved identifiers

This was changed intentionally in bug 240317. However, IE does not allow all "future reserved" keywords, its output is included as a comment in this script. Opera 8.51 allows them all except goto.

Comment 3

[Bob Clary [:bc] (inactive)]

Yeah, we gained compatibility by sacrificing ecma correctness. I don't see much to be gained by 100% compatibility though. If someone disagrees, please reopen. WONTFIX.

Comment 4

[Brendan Eich [:brendan]]

I'd like to see what IE reserves, and what it doesn't.  Please post the output of Seno.Aiko's attachment on modern IE.  It may be that the fix for bug 240317 was too aggressive in unreserving, and class (not char) is coming in Edition 4 / JS2.  Thanks,

/be

Comment 5

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #4)
> I'd like to see what IE reserves, and what it doesn't.  Please post the output
> of Seno.Aiko's attachment on modern IE.

I get the same output as that in the attachment.
view-source:https://bugzilla.mozilla.org/attachment.cgi?id=206492&action=view

Comment 6

[:Gavin Sharp [email: [e-mail]]]

To be clear, the difference between IE6 on windows and Firefox 1.5 is that in Firefox:
class is accepted as an identifier.
enum is accepted as an identifier.
extends is accepted as an identifier.
super is accepted as an identifier.

Comment 7

[Brendan Eich [:brendan]]

(In reply to comment #6)
> To be clear, the difference between IE6 on windows and Firefox 1.5 is that in
> Firefox:

Thanks, Gavin -- helps us Linux users reading bugmail with no Windows box handy.

> class is accepted as an identifier.
> enum is accepted as an identifier.
> extends is accepted as an identifier.
> super is accepted as an identifier.

Ok, enum is strange of IE, but perhaps enum is implemented in JScript.NET or some such future version.

The rest are good to reserve in light of JS2/ES4.  We should do likewise, in order to match the dominant browser.  If someone can confirm in IE7 beta and IE5.5 that would be good.  Another case of real-world web standards trumping de-jure ones.

We should fix this *after* Igor's work in bug 319719 is done and landed.

/be

Comment 8

[Brendan Eich [:brendan]]

(In reply to comment #7)
> (In reply to comment #6)
> > To be clear, the difference between IE6 on windows and Firefox 1.5 is that in
> > Firefox:
> 
> Thanks, Gavin -- helps us Linux users reading bugmail with no Windows box
> handy.

And us lusers who don't view-source! :-P

/be

Comment 9

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #7)
> If someone can confirm in IE7 beta and IE5.5 that would be good.

Tested both, same results as with IE6.

Comment 10

[Baron Schwartz]

There are differences in which future reserved words are allowed in Firefox between Windows and Mac.  I have found that 'char' is allowed in Windows, but not Mac.

Comment 11

[Brendan Eich [:brendan]]

(In reply to comment #10)
> There are differences in which future reserved words are allowed in Firefox
> between Windows and Mac.  I have found that 'char' is allowed in Windows, but
> not Mac.

You must be using an older version of Firefox on the Mac, then.

1.0 reserved all Java chars, as SpiderMonkey has done forever.

1.5 contains changes to SpiderMonkey that unreserved char and the rest of the Java keywords not already reserved by JS.

Please check your about: and about:buildconfig results.

/be

Comment 12

[Brendan Eich [:brendan]]

(In reply to comment #11)
> 1.0 reserved all Java chars, as SpiderMonkey has done forever.

Urgh, Java keywords.

Anyway, the point is that there are no platform dependencies to this code.  Mac and Windows are the same.  If you are seeing a difference in 1.5 on both, perhaps you have enabled strict warnings in one profile but not the other?

/be

Comment 13

[Tim Funk]

It would be nice that when 'class' were used as a variable (such as document.getElementById('foo').class='bar' instead of document.getElementById('foo').className='bar') a warning would be invoked in the console. 

Comment 14

[Brendan Eich [:brendan]]

We should decide how to go here.  Choices:

1.  Emulate IE, reserving only class, enum, extends, and super.

2.  Reserve all the ECMA-262 Edition 3 identifiers.

3.  Reserve every identifier we think Edition 4 will reserve.

I've argued at length elsewhere (http://groups.google.com/groups?selm=ce9ml4$5rt1%40ripley.netscape.com) that Firefox and other minority share browsers must imitate IE to gain market share, specifically to avoid being excluded from distribution channels; as well as to work with content generated by less than top-tier authors who test mainly/only IE.

This is a short- to medium-term strategy, after which we have enough share, and especially enough clout with content authors, to lead the other way: with WHATWG incremental innovation, where the cool stuff we do works in Safari and Opera, and can be emulated cheaply on IE.  Or we just have enough cachet to promulgate de-facto standards.

With JS2, or JS1.9 which is what I expect we will ship in Gecko 1.9, we will be leading browsers toward ECMA-262 Edition 4.  We want script written over the last ten years to migrate over the next ten (sooner is better) to use Edition 4.  And I expect other browsers will follow, although it will take years.

Bug 240317 was filed because some script on the web used "char" as a parameter name. If such cases are rare, Safari will continue to break them, and we can get any of those pages that actually matter to enough users to cost us Firefox adoption to fix their scripts, then the current bug may demonstrate a case where emulating IE (1) is no longer helpful to Firefox adoption, and we should switch to our longer-term strategy.

If we do this, then we should do (3), not (2).

Comments welcome.  I wish we could measure content author market share, that is, how many authors test in Firefox.  Even then, we would want to know how much bad content would break if we do (3), and whether that content is owned enough to expect evangelism to help get it fixed.  Bob, any ideas?

/be

Comment 15

[Bob Clary [:bc] (inactive)]

(In reply to comment #14)

> 
> Comments welcome.  I wish we could measure content author market share, that
> is, how many authors test in Firefox.  Even then, we would want to know how
> much bad content would break if we do (3), and whether that content is owned
> enough to expect evangelism to help get it fixed.  Bob, any ideas?
> 

I think we are in a unique position today that we should recogonize and continue our leadership by inviting the other browser developers from Microsoft, Apple, Opera and KDE to work with us to move towards JS2.

For example, one of the problems we face is the lack of script hiding in other browsers through the use of the script type attribute. This will make it difficult to support the new features we envision since the other browsers may attempt to load new JS2 content and barf.

If we can get the others to adapt their existing browsers to ignore properly qualified javascript versions which they do not support, we and they will be free to experiment in the version 1.9 space as we move towards 2.0.

This should be part of an overall collaborative effort between all of the browser vendors to determine where we want the web platform to evolve. Microsoft may not want to play however their recent movements in the RSS area and in their increased support for CSS standards in IE7 may mean they are willing to be good citizens of the web going forward and we should give them the opportunity to prove it. Regardless of what Microsoft does, we should work with the other WHATWG members to push forward.

In summary, I think we should lead but not do it in a vacuum. Lets invite everyone to play and only go it alone if they refuse to be nice.

Comment 16

[Tom S [:evilpie]]

Test is at ecma_5/misc/future-reserved-words.js