744784 - Allow keywords as identifiers if at least one character is represented by a Unicode escape

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Mathias Bynens]

See http://wiki.whatwg.org/wiki/Web_ECMAScript#Identifiers:

> Identifiers containing escape sequences are not equivalent to fully
> unescaped identifiers in the case that, after fully unescaping identifier,
> it is a ReservedWord. In particular it is possible to create Identifiers
> that unescape to a reserved word so long as at least one character is fully
> escaped. Subsequent use of such identifiers must also have at least one
> character escaped (otherwise the reserved word will be used instead) but it
> need not be the same character(s) as that originally used to create the
> identifier.

For example, this should alert 'PASS':

    function \u0074rue() { alert('PASS'); }
    \u0074rue();

So should this:

    function \u0074rue() { alert('PASS'); }
    tru\u0065();

Comment 1

[Tom S [:evilpie]]

Well, I think we should not allow this kind of functions. We already correctly treat escaped identifiers as keywords in every other case.

>var \u0074rue; /* SyntaxError */

It think that we allow them as function names is just an oversight and we should probably not allow that. I tried to reply to your question on twitter with the relevant Bug 638667, but I think I failed a bit there.

Because it looks like we haven't had any complains about this in the past, we should not allow more things now. (Contrary to the ES5 from my understanding)

Comment 2

[Allen Wirfs-Brock]

My reading of ES5 (and I wrote the text) does not allow the above.  However the ES3 spec. might be interpreted as allowing it. 

I don't think anything should change until T39 decides what we really want to allow/disallow going forward.

Comment 3

[Tom S [:evilpie]]

>(Contrary to the ES5 from my understanding)
Badly worded, just to make it clear, ES5 does not allow keywords even as escaped identifiers.

http://es5.github.com/#x7.6

>All interpretations of identifiers within this specification are based upon their actual >characters regardless of whether or not an escape sequence was used to contribute any >particular characters.

Comment 4

[Brendan Eich [:brendan]]

See https://bugs.ecmascript.org/show_bug.cgi?id=277 which this bug should depend on (if only we had cross-bugzilla-instance dependencies!).

/be

Comment 6

[Mathias Bynens]

FTR, the compatibility requirements are now listed here: http://mathias.html5.org/specs/javascript/#escaped-reserved-words

Firefox is the only browser to error on “identifiers” like these. It may be correct behavior as per the ECMAScript spec (and in a perfect world, all engines would implement it like this, and no one would use identifiers like that), but it doesn’t match other implementations. I’m not sure how strong the compatibility requirements are, but it is a risk.

Please consider reverting the change in bug 770856 for compatibility/interoperability reasons.

Tests: http://mathias.html5.org/tests/javascript/identifiers/

Comment 7

[Allen Wirfs-Brock]

(In reply to Mathias Bynens from comment #6)
> FTR, the compatibility requirements are now listed here:
> http://mathias.html5.org/specs/javascript/#escaped-reserved-words
> 
> Firefox is the only browser to error on “identifiers” like these. 

that's not correct. At least IE8 and IE9 (and almost certainly pre-IE8, but I haven't tested) do not recognize such identifiers. 

So, this has never been a real interoperability requirement of the web. It has also been discussed on es-discuss and future versions of the ECMAScript specification are not going to make such identifiers legal.

Rather than pushing browsers to converge on something that been explicitly determined to be an undesirable and non-standard feature, we should be pushing browsers to converge on correctly implementing the standards. 

This should be resolved as invalid or wontfix

Comment 8

[Mathias Bynens]

Okay, let’s try to get other browsers/engines to remove this non-standard extension as well, then. I’ve filed the following bugs:

* Opera/Carakan bug: https://bugs.opera.com/browse/DSK-369398
* Chrome/V8: http://code.google.com/p/v8/issues/detail?id=2222
* Safari/JavaScriptCore: https://bugs.webkit.org/show_bug.cgi?id=90678

Comment 9

[Mark S. Miller]

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

Comment 10

[Tom S [:evilpie]]

Per Bug 694360, we treat var thi\u0073; as a syntax error.

Comment 11

[Mark S. Miller]

So close this bug?

Comment 12

[Anne (:annevk)]

Resolving WONTFIX since we don't want to implement comment 0 and are following ES6 due to bug 694360. If other engines fail to fix this I'm sure a new bug will be opened against us.