Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 744784 - Allow keywords as identifiers if at least one character is represented by a Unicode escape
: Allow keywords as identifiers if at least one character is represented by a U...
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: x86 Mac OS X
: -- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Jason Orendorff [:jorendorff]
: 770856 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2012-04-12 08:03 PDT by Mathias Bynens
Modified: 2014-08-14 00:40 PDT (History)
7 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description Mathias Bynens 2012-04-12 08:03:56 PDT

> 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'); }

So should this:

    function \u0074rue() { alert('PASS'); }
Comment 1 Tom Schuster [:evilpie] 2012-04-12 09:06:36 PDT
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 2012-04-12 09:21:56 PDT
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 Schuster [:evilpie] 2012-04-12 09:36:37 PDT
>(Contrary to the ES5 from my understanding)
Badly worded, just to make it clear, ES5 does not allow keywords even as escaped identifiers.

>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] 2012-04-12 10:06:10 PDT
See which this bug should depend on (if only we had cross-bugzilla-instance dependencies!).

Comment 5 Mathias Bynens 2012-07-04 05:52:32 PDT
*** Bug 770856 has been marked as a duplicate of this bug. ***
Comment 6 Mathias Bynens 2012-07-04 06:21:01 PDT
FTR, the compatibility requirements are now listed here:

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.

Comment 7 Allen Wirfs-Brock 2012-07-04 08:38:50 PDT
(In reply to Mathias Bynens from comment #6)
> FTR, the compatibility requirements are now listed here:
> 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 2012-07-06 05:51:37 PDT
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:
* Chrome/V8:
* Safari/JavaScriptCore:
Comment 9 Mark S. Miller 2014-05-11 11:01:56 PDT
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 Schuster [:evilpie] 2014-05-11 11:07:07 PDT
Per Bug 694360, we treat var thi\u0073; as a syntax error.
Comment 11 Mark S. Miller 2014-05-11 11:14:47 PDT
So close this bug?
Comment 12 Anne (:annevk) 2014-08-14 00:40:40 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.