Closed
Bug 306664
Opened 19 years ago
Closed 19 years ago
Bump JS version to 1.6, for E4X + Array extra + Array/String generics
Categories
(Core :: JavaScript Engine, defect, P1)
Core
JavaScript Engine
Tracking
()
VERIFIED
FIXED
mozilla1.8beta4
People
(Reporter: brendan, Assigned: brendan)
Details
(Keywords: fixed1.8, js1.6)
Attachments
(1 file, 1 obsolete file)
14.19 KB,
patch
|
mrbkap
:
review+
shaver
:
superreview+
brendan
:
approval1.8b4+
|
Details | Diff | Splinter Review |
Nanto suggested this in email to me, and noted how it happens to match Rhino's version that added E4X support. /be
Assignee | ||
Comment 1•19 years ago
|
||
I'd like to get this into the first beta, so we don't have to unleash it on the second beta or later in the 1.5 game. Asa, I guess this should really have a "js1.6" keyword. Can you add that? /be
Status: NEW → ASSIGNED
Flags: blocking1.8b4+
Priority: -- → P1
Target Milestone: --- → mozilla1.8beta4
Comment 2•19 years ago
|
||
js1.6 keyword has been created and added to this bug.
Comment 3•19 years ago
|
||
I think JavaScript version number 1.6 should enable E4X support, like this: <script type="application/javascript; version=1.6"> // <![CDATA[ var xml = <element/>; // ]]> </script> This hides scripts from IE, Opera 7/8, and NN 4 for Windows. (Because I have only Windows, I'm not sure about Safari, Konqueror, iCab, and etc.) So I think to enable E4X in JS labeled as version 1.6 doesn't have adverse effects for browsers without E4X support.
Comment 4•19 years ago
|
||
Don't forget to remove array extra information from the JS1.5 part of devmo!
Assignee | ||
Comment 5•19 years ago
|
||
The only way to implement this so that 1.6 => E4X is to make JS_HAS_XML_OPTION(cx) test both the JSVERSION_HAS_XML bit reflected from JS_SetOptions(cx, JSOPTION_XML | JS_GetOptions(cx)), and whether the version number in cx->version is >= 160. /be
Attachment #194989 -
Flags: superreview?(shaver)
Attachment #194989 -
Flags: review?(mrbkap)
Assignee | ||
Comment 6•19 years ago
|
||
Comment on attachment 194989 [details] [diff] [review] proposed change Oops, forgot to copy the working patch to my staging area... new patch in a minute. /be
Attachment #194989 -
Attachment is obsolete: true
Attachment #194989 -
Flags: superreview?(shaver)
Attachment #194989 -
Flags: review?(mrbkap)
Assignee | ||
Comment 7•19 years ago
|
||
This is straightforward, except that I made nsScriptLoader::EvaluateScript match nsXULPrototypeScript::Compile in clearing JSOPTION_XML if e4x=0 or no e4x param was given on the MIME type. This is important for HTML/XUL consistency: it keeps two script tags, the first with e4x=1, the second without, from interfering with one another's options. Note well that with the version=1.6 param, there is no way to turn off e4x, so no way to do the ancient comment-hiding hack for pre-Netscape-2 browsers. This is probably ok -- it's been about 10 years since Netscape 2 beta 2, IIRC. /be
Attachment #194991 -
Flags: superreview?(shaver)
Attachment #194991 -
Flags: review?(mrbkap)
Assignee | ||
Updated•19 years ago
|
Whiteboard: [waiting for review]
Attachment #194991 -
Flags: superreview?(shaver) → superreview+
Comment 8•19 years ago
|
||
Comment on attachment 194991 [details] [diff] [review] correct patch r=mrbkap
Attachment #194991 -
Flags: review?(mrbkap) → review+
Assignee | ||
Updated•19 years ago
|
Attachment #194991 -
Flags: approval1.8b4+
Assignee | ||
Comment 9•19 years ago
|
||
Fixed on trunk and branch. /be
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Keywords: fixed1.8
Resolution: --- → FIXED
Whiteboard: [waiting for review]
Comment 10•19 years ago
|
||
If you have time, can you supply a list of non-E4X changes between JS 1.5 and 1.6, including new features and notable bug fixes, and post it on Devmo? Thanks.
Assignee | ||
Comment 11•19 years ago
|
||
(In reply to comment #10) > If you have time, can you supply a list of non-E4X changes between JS 1.5 and > 1.6, including new features and notable bug fixes, and post it on Devmo? Thanks. No. :-P The release notes for the SpiderMonkey 1.6 tarball that we had thought of as yet another release candidate (RC) for 1.5 will tell what was fixed since the last 1.5 RC. That release will match Firefox 1.5's JS engine, so will happen later this year, not too late. This bug is about configuration controls and defaults for JS1.6, which do *not* enable and disable the hundreds or thousands of bugfixes since 1.5 was first unleashed many years ago. Just to reiterate what's already in the code: - JS_VERSION is a compile-time control for enabling and disabling some (but not all) features and ancient bugfixes that vary among versions. Since ECMA Ed. 1, the newer values for JS_VERSION have mainly added extensions, some of which (with changes or fixes) fed into later ECMA-262 Editions. If you compile with a higher JS_VERSION, then no matter what run-time version is selected, almost all of the extensions enabled by that version will be available. This allows object detection at run-time by scripts. It applies to the new Array and String generics. That is, even in <script language="JavaScript"> or a similar tag with a version suffix, Array.join is a generic shorthand for Array.join.call. - Given a JS_VERSION macro definition, compiling SpiderMonkey results in a JS engine that can also be told, at run-time, what version to use, selecting from JSVERSION_DEFAULT, JSVERSION_1_2, etc. This run-time control affects only a few hard cases where we had to retain backward compatibility, and generally does not hide or reveal extensions or pure bugfixes via run-time version checks. Almost all fixes are are baked into code that is not conditionally compiled (not enclosed by #if...#endif) at all. Code extending native class prototypes and constructors with methods is conditionally compiled, but again, once you've compiled for a recent version, setting the run-time version to an older version hides nothing. So, in general very little is conditioned at run-time, at least since the bad old pre-ECMA Edition 1 days of JS1.2. The default version and the explicit 1.6 version are quite similar, except for E4X scanning: in the default version, without an explicit JS_SetOptions(cx, JSOPTION_XML | JS_GetOptions(cx)), an XML comment is interpreted as an SGML comment's outer delimiters were since the Netscape 2 days, to enable the "comment hiding hack" by which JS could be used in (implicitly) CDATA sections of <script> tags that pre-Netscape-2 browsers could display without showing the script. Via a JS lexical extension, the first line of the SGML comment was ignored. This looked like: <script> <!-- comment everything from old browsers, but just this line from JS script code goes here // end of SGML comment: --> </script> With E4X, either enabled on top of the default or an older run-time version via the e4x=1 MIME type parameter, viz, <script type="application/javascript; e4x=1"> or implicitly on with <script language="JavaScript1.6"> or <script type="application/javascript; version=1.6"> Such an SGML comment would be scanned as an XML comment and none of the script code would be evaluated. /be
Assignee | ||
Comment 12•19 years ago
|
||
See bug 255895 comment 27 for what I wrote previously about versioning in SpiderMonkey. /be
Comment 13•19 years ago
|
||
the js1_6 tests in the test library cover this.
Status: RESOLVED → VERIFIED
Flags: testcase+
You need to log in
before you can comment on or make changes to this bug.
Description
•