249211 - export and import statement reconized has a reserved identifier

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect, P1)

Description

[David Courtin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7) Gecko/20040616
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.7) Gecko/20040616

We are trying to use the export and import statement as describe in the
javascript documentation see :
http://devedge.netscape.com/library/manuals/2000/javascript/1.3/reference/stmt.html#1016648

The source code in the a.html file look like this :
<script language="JavaScript1.4">
 
      function tictac() {
         // here we have some code
      }

      export tictac();
    </script>

The error in the javascript console is :
Error: export is a reserved identifier
Source File: http://localhost:8080/icmnet/a.html
Line: 23, Column: 6
Source Code:
      export tictac();

In another html file we have an import statement, it's look like this :
<script language="JavaScript1.4">
      import *;
</script>

The error in the javascript console is :
Error: import is a reserved identifier
Source File: http://localhost:8080/icmnet/b.html
Line: 6, Column: 6
Source Code:
      import *;

We need this because we want to use some secure code that is signed in a jar
file in a non-signed page generated by a Tomcat server.

May be it's a wrong way to try doing this like that, but we didn't find any other...

Thank you for your help.


Reproducible: Always
Steps to Reproduce:

Comment 1

[David Courtin]

After several more tests it seems to be bug specific to the new version of
mozilla  1.7 or firefox 0.9. Thoses export/import statements work perfectly well
on Mozilla 1.6 and Firefox 0.8.

An other link for testing this functionality can be found here :
http://developer.netscape.com/docs/manuals/communicator/jssec/contents.htm

Comment 2

[Brendan Eich [:brendan]]

Support for non-standard Netscape 4 export/import in JS was decompiled in 1.7,
to save footprint.  This broke at least David.

What I'm concerned about now, though, is do we want this non-standard feature as
part of our signed script model, as it was in 4.x?  This is a 4xp bug, for sure;
but should it be WONTFIXed?

What's our forward-looking plan, if any?  Does any other browser address the
problem of using functions from window A in window B by importing them, even
though A loads signed scripts and the functions have elevated privs?  The way we
allowed this in 4.x is scary: it requires JS authors to be extremely careful in
how they enable privileges in functions from A, and to avoid leaking anything,
or otherwise exposing a hole.

/be

Comment 3

[Johnny Stenback (:jst)]

Hmm, that's really unfortunate. How much footprint are we talking about here?

Comment 4

[Brendan Eich [:brendan]]

About 5K for my DEBUG optimized libmozjs (gcc 3.3.2).

/be

Comment 5

[Brendan Eich [:brendan]]

Looking at
http://axolotl.mozilla.org/graph/query.cgi?tbox=luna.mozilla.org&testname=codesize_embed&autoscale=1&size=&units=bytes&ltype=&points=&showpoint=2004%3A07%3A15%3A11%3A34%3A39%2C11865822&avg=0&days=230,
the raw data, struggling to correlate dates with CVS's UTC-stamped log entry for
jsconfig.h, it looks like mZ went down about 3.2K.

/be

Comment 6

[Brendan Eich [:brendan]]

This is obviously too incompatible a change.  I had hoped to save footprint by
losing a 4xp, non-ECMA extension, but the trade-off compares apples and oranges.
 At this point, I'd rather be compatible.  I'll make up the footprint elsewhere,
I swear.

/be

Comment 7

[Brendan Eich [:brendan]]

Attachment: just checked into the 1.8a3 trunk

Going for aviary1.0 and 1.7.2 approval on this patch.

/be

Comment 8

[Mike Kaply [:mkaply]]

Comment on attachment 153327 [details] [diff] [review]
just checked into the 1.8a3 trunk

a=mkaply for 1.7.2

Comment 9

[Brendan Eich [:brendan]]

Fixed on both AVIARY_1_0_20040515_BRANCH and MOZILLA_1_7_BRANCH.

/be

Comment 10

[Brendan Eich [:brendan]]

This was checked in on the 1.8a3 trunk yesterday.  It's fixed everywhere!

/be

Comment 11

[Frederic Crozat]

FYI, this patch didn't landed on aviary nor 1.7.5 branch :(

Comment 12

[Brendan Eich [:brendan]]

Frederic, what are you talking about?

$ cvs up -p -rMOZILLA_1_7_BRANCH jsconfig.h | grep EXPORT
===================================================================
Checking out jsconfig.h
RCS:  /cvsroot/mozilla/js/src/jsconfig.h,v
VERS: 3.30.4.1
***************
#define JS_HAS_EXPORT_IMPORT    0       /* has export fun; import obj.fun */
#define JS_HAS_EXPORT_IMPORT    0       /* has export fun; import obj.fun */
#define JS_HAS_EXPORT_IMPORT    0       /* has export fun; import obj.fun */
#define JS_HAS_EXPORT_IMPORT    1       /* has export fun; import obj.fun */
#define JS_HAS_EXPORT_IMPORT    1       /* has export fun; import obj.fun */
#define JS_HAS_EXPORT_IMPORT    1       /* has export fun; import obj.fun */
#define JS_HAS_EXPORT_IMPORT    1       /* has export fun; import obj.fun */
$ cvs up -p -rAVIARY_1_0_20040515_BRANCH jsconfig.h | grep EXPORT
===================================================================
Checking out jsconfig.h
RCS:  /cvsroot/mozilla/js/src/jsconfig.h,v
VERS: 3.30.8.1
***************
#define JS_HAS_EXPORT_IMPORT    0       /* has export fun; import obj.fun */
#define JS_HAS_EXPORT_IMPORT    0       /* has export fun; import obj.fun */
#define JS_HAS_EXPORT_IMPORT    0       /* has export fun; import obj.fun */
#define JS_HAS_EXPORT_IMPORT    1       /* has export fun; import obj.fun */
#define JS_HAS_EXPORT_IMPORT    1       /* has export fun; import obj.fun */
#define JS_HAS_EXPORT_IMPORT    1       /* has export fun; import obj.fun */
#define JS_HAS_EXPORT_IMPORT    1       /* has export fun; import obj.fun */

/be

Comment 13

[Frederic Crozat]

My bad, I had an incorrect patch on my own tree which was still applying and I
wasn't looking at the code correctly..

Sorry for the false alarm.

Comment 14

[Bob Clary [:bc] (inactive)]

Attachment: js1_5/Regress/regress-249211.js

David, with your permission this will be included in the javascript test
library.

Comment 15

[Bob Clary [:bc] (inactive)]

No reply from David, but the test case is sufficiently different that I have
checked it in as js/tests/js1_5/Regress/regress-249211.js.

Comment 16

[David Courtin]

Sorry I've not see your request. Of course there's no problem for me.