New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 19 users

Issue metadata

Status: Duplicate
Merged: issue 1972
Owner: ----
Closed: Nov 2015
Cc:
HW: ----
NextAction: ----
OS: ----
Priority: 3
Type: FeatureRequest



Sign in to add a comment

Drop the “escaped reserved words as identifiers” compatibility measure

Project Member Reported by math...@qiwi.be, Jul 6 2012

Issue description

For example, `var var;` throws a syntax error, but e.g. `var v\u0061r;` works fine, currently. This is a violation of the ECMAScript 5.1 spec, and used to be a compatibility requirement: http://mathias.html5.org/specs/javascript/#escaped-reserved-words One year ago, all browsers except IE fulfilled this.

Half a year ago Firefox dropped this non-standard addition (https://bugzilla.mozilla.org/show_bug.cgi?id=694360) and hasn’t seen any compatibility issues since.

Please align with Firefox and IE by removing this non-standard extension.

Relevant JavaScriptCore bug: https://bugs.webkit.org/show_bug.cgi?id=90678
 
Cc: rossberg@chromium.org
Labels: Type-FeatureRequest ES5
This is a spec ambiguity that still awaits resolution, see:

https://bugs.ecmascript.org/show_bug.cgi?id=277

We won't change the current behaviour until the spec is clarified.

Comment 3 by math...@qiwi.be, Sep 18 2013

FWIW, Allen already marked that bug as accepted and said:

> Based on this, for ES6 I will make it clear that escaped flags are not allowed.

Are you waiting for the spec to be finalized or can this be fixed now?
Cc: mstarzinger@chromium.org
Labels: -ES5 Priority-Low Harmony
Status: Accepted
Summary: Drop the “escaped reserved words as identifiers” compatibility measure (was: JavaScript: Drop the “escaped reserved words as identifiers” compatibility measure)
It's resolved for ES6 now and we will fix it. But obviously, it has rather low priority.

Comment 5 by erights@gmail.com, May 11 2014

What is the status of this? It is security significant for systems that filter or translate code in order to enforce restrictions.

Since this is old behaviour, is it fair to assume that existing tools know how to work around it?

Comment 7 by erights@gmail.com, May 12 2014

The existing tools I know about, yes.

Comment 8 by math...@qiwi.be, Aug 14 2014

Cc: arv@chromium.org

Comment 9 by math...@qiwi.be, Mar 10 2015

FWIW, this is the only failing test on https://mathias.html5.org/tests/javascript/identifiers/.

Comment 10 by habl...@google.com, Apr 29 2015

Status: Available

Comment 11 by math...@qiwi.be, Jun 10 2015

Safari/JavaScriptCore just made this change. https://trac.webkit.org/changeset/185414

Comment 12 by math...@qiwi.be, Jun 13 2015

 Issue 4185  has been merged into this issue.

Comment 13 by m...@bocoup.com, Jun 22 2015

This bug also leads to strange behavior for the case of the `this` keyword specifically:

    $ d8 -e "var this;"
    unnamed:1: SyntaxError: Unexpected token this
    var this;
        ^^^^
    SyntaxError: Unexpected token this

...but

    $ d8 -e "var thi\u0073;"
    unnamed:1: TypeError: Identifier 'this' has already been declared
    var thi\u0073;
    ^
    TypeError: Identifier 'this' has already been declared
        at unnamed:1:1

Comment 14 by adamk@chromium.org, Aug 18 2015

Firefox seems to have become overly-relaxed, as it now allows unicode escapes to result in keywords where they are allowed, e.g.:

v\u0061r foo = 1

test262 doesn't seem to cover this case. Haven't gotten a chance to test JSC's new behavior yet.
Mergedinto: 1972
Status: Duplicate
Labels: Priority-3

Sign in to add a comment