306664 - Bump JS version to 1.6, for E4X + Array extra + Array/String generics

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect, P1)

Description

[Brendan Eich [:brendan]]

Nanto suggested this in email to me, and noted how it happens to match Rhino's
version that added E4X support.

/be

Comment 1

[Brendan Eich [:brendan]]

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

Comment 2

[Asa Dotzler [:asa]]

js1.6 keyword has been created and added to this bug. 

Comment 3

[nanto_vi (TOYAMA Nao)]

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

[Doug Wright]

Don't forget to remove array extra information from the JS1.5 part of devmo!

Comment 5

[Brendan Eich [:brendan]]

Attachment: proposed change

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

Comment 6

[Brendan Eich [:brendan]]

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

Comment 7

[Brendan Eich [:brendan]]

Attachment: correct patch

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

Comment 8

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 194991 [details] [diff] [review]
correct patch

r=mrbkap

Comment 9

[Brendan Eich [:brendan]]

Fixed on trunk and branch.

/be

Comment 10

[Yuh-Ruey Chen]

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.

Comment 11

[Brendan Eich [:brendan]]

(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

Comment 12

[Brendan Eich [:brendan]]

See bug 255895 comment 27 for what I wrote previously about versioning in
SpiderMonkey.

/be

Comment 13

[Bob Clary [:bc] (inactive)]

the js1_6 tests in the test library cover this.