The original Safari "bug": http://bugzilla.opendarwin.org/show_bug.cgi?id=6179
Created attachment 206492 [details] 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.
Assignee: nobody → general
OS: MacOS X → All
Product: Firefox → Core
QA Contact: general → general
Hardware: Macintosh → All
Version: unspecified → Trunk
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Depends on: 240317
Resolution: --- → WONTFIX
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
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
(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
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.
(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
Status: UNCONFIRMED → NEW
Ever confirmed: true
(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
(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.
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.
(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
(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
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.
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
Test is at ecma_5/misc/future-reserved-words.js
Status: NEW → RESOLVED
Last Resolved: 13 years ago → 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.