Discuss
  • Fun impossible Firefox JS challenge

Fun impossible Firefox JS challenge

# gaz Heyes (13 years ago)

Hey all

Just thought I'd post a bit of fun related to the Firefox JS parser.

!function(){

function true(){alert('Call me');};

/* YOUR CODE */

}();

The trick is to execute the function "true" from within the function expression.

Rules:

  1. Your code must be within the function expression as indicated by the comment.
  2. You cannot redefine "true" anywhere else including window etc.
  3. You must call the actual function as defined in the original code.

This is just for fun and should be impossible but it does highlight a couple of things, 1) JavaScript has no way to reference inner functions that are not a property of the object without directly calling their name. 2) Mozilla JS devs are crazy (in a nice way)

# Lasse Reichstein (13 years ago)

On Thu, Apr 12, 2012 at 2:58 PM, gaz Heyes <gazheyes at gmail.com> wrote:

function true(){alert('Call me');};

Is this a deliberate Mozilla change, or just a bug ("true" being a keyword and not valid as a function name in plain ECMAScript)?

And, btw, /* MY CODE */ tru\u0065();

# gaz Heyes (13 years ago)

On 12 April 2012 14:51, Lasse Reichstein <reichsteinatwork at gmail.com> wrote:

On Thu, Apr 12, 2012 at 2:58 PM, gaz Heyes <gazheyes at gmail.com> wrote:

function true(){alert('Call me');};

Is this a deliberate Mozilla change, or just a bug ("true" being a keyword and not valid as a function name in plain ECMAScript)?

And, btw, /* MY CODE */ tru\u0065();

Haha nice try even with unicode escapes it still refers to "true" the boolean not the function.

# Andreas Rossberg (13 years ago)

On 12 April 2012 16:11, gaz Heyes <gazheyes at gmail.com> wrote:

On 12 April 2012 14:51, Lasse Reichstein <reichsteinatwork at gmail.com> wrote:

On Thu, Apr 12, 2012 at 2:58 PM, gaz Heyes <gazheyes at gmail.com> wrote:

function true(){alert('Call me');};

Is this a deliberate Mozilla change, or just a bug ("true" being a keyword and not valid as a function name in plain ECMAScript)?

And, btw,  /* MY CODE */  tru\u0065();

Haha nice try even with unicode escapes it still refers to "true" the boolean not the function.

That's another FF deviation from the standard, though.

# gaz Heyes (13 years ago)

On 12 April 2012 15:12, Andreas Rossberg <rossberg at google.com> wrote:

That's another FF deviation from the standard, though.

Well it's possible to do as I've just done it but deviation from the standard isn't a valid answer sorry :P

# Peter van der Zee (13 years ago)

On Thu, Apr 12, 2012 at 4:12 PM, Andreas Rossberg <rossberg at google.com> wrote:

Haha nice try even with unicode escapes it still refers to "true" the boolean not the function.

That's another FF deviation from the standard, though.

Identifiers with unicode escapes have the meaning of their canonical value. So wouldn't that (tru\u0065 referring to the bool) be valid and according to the spec?

# crypticswarm (13 years ago)

!function(){ function true(){alert('Call me');}; /* YOUR CODE / new Function('(' + ('' + arguments.callee).match(/function.+?{\s([\s\S]*?})/)[1] + '())')() }()

It calls a function true but maybe not the function true

# gaz Heyes (13 years ago)

On 12 April 2012 15:34, crypticswarm <crypticswarm at gmail.com> wrote:

!function(){ function true(){alert('Call me');}; /* YOUR CODE / new Function('(' + ('' + arguments.callee).match(/function.+?{\s([\s\S]*?})/)[1] + '())')() }()

It calls a function true but maybe not the function true

That is lame. Try harder.

# Mathias Bynens (13 years ago)

On Thu, Apr 12, 2012 at 3:51 PM, Lasse Reichstein wrote:

/* MY CODE */ tru\u0065();

That would only work if the true function was defined with at least one Unicode escape in the name (not necessarily the same one). See mathiasbynens.be/notes/javascript-identifiers#valid-identifier-names:

[…] This means that you can use var \u0061 and var a interchangeably. Similarly, since var 1 is invalid, so is var \u0031.

For web browsers, there is an exception to this rule, namely when reserved words are used. Browsers must support identifiers that unescape to a reserved word, as long as at least one character is escaped using a Unicode escape sequence. For example, var var; wouldn’t work, but e.g. var v\u0061r; would — even though strictly speaking, the ECMAScript spec disallows it. Subsequent use of such identifiers must also have at least one character escaped (otherwise the reserved word will be used instead), but it doesn’t have to be the same character(s) that were originally used to create the identifier. For example, var v\u0061r = 42; alert(va\u0072); would alert 42.

P.S. If you’re wondering why function true() {} is allowed in Firefox, see bugzilla.mozilla.org/show_bug.cgi?id=638667.

# Andreas Rossberg (13 years ago)

On 12 April 2012 16:27, Peter van der Zee <ecma at qfox.nl> wrote:

On Thu, Apr 12, 2012 at 4:12 PM, Andreas Rossberg <rossberg at google.com> wrote:

Haha nice try even with unicode escapes it still refers to "true" the boolean not the function.

That's another FF deviation from the standard, though.

Identifiers with unicode escapes have the meaning of their canonical value. So wouldn't that (tru\u0065 referring to the bool) be valid and according to the spec?

Yes, but keywords (and other verbatim tokens, like 'true') are recognized before canonicalization. At least that is the intention of the spec, Waldemar told me. (I filed ecmascript#277 a few weeks ago as a request for making the wording clearer.)

# Mathias Bynens (13 years ago)

For those interested, Spidermonkey doesn’t handle the following correctly:

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

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

Both these examples should alert 'PASS' in web browsers.

I filed this as bug 744784: bugzilla.mozilla.org/show_bug.cgi?id=744784

# Domenic Denicola (13 years ago)

The real question is, are there test-262's for this behavior? Or for the original nonconforming function true() { }?

# Andreas Rossberg (13 years ago)

On 12 April 2012 17:19, Domenic Denicola <domenic at domenicdenicola.com> wrote:

The real question is, are there test-262's for this behavior? Or for the original nonconforming function true() { }?

No, there aren't. IIRC, I had filed a bug for that, too. :)

# Allen Wirfs-Brock (13 years ago)

On Apr 12, 2012, at 8:06 AM, Andreas Rossberg wrote:

On 12 April 2012 16:27, Peter van der Zee <ecma at qfox.nl> wrote:

On Thu, Apr 12, 2012 at 4:12 PM, Andreas Rossberg <rossberg at google.com> wrote:

Haha nice try even with unicode escapes it still refers to "true" the boolean not the function.

That's another FF deviation from the standard, though.

Identifiers with unicode escapes have the meaning of their canonical value. So wouldn't that (tru\u0065 referring to the bool) be valid and according to the spec?

Yes, but keywords (and other verbatim tokens, like 'true') are recognized before canonicalization. At least that is the intention of the spec, Waldemar told me. (I filed ecmascript#277 a few weeks ago as a request for making the wording clearer.)

A couple points:

Floating around this area (in Mathias' blog post and Andreas' bug report, etc)) there are references to wiki.whatwg.org/wiki/Web_ECMAScript#Identifiers . It should be used justify any particular interpretation of the ES specification. There is nothing normative about that document and the section on Identifiers is actually labelled as "this is very rough". Nobody should be making implementation decisions on the basis of that document.

There may well be web compatibility requirements that are not covered by the current ES5.1 spec. We should try to understand those requirements before implementations start trying to match each others deviations from the spec. Difference between implementations suggest areas where there currently isn't complete interoperability in this area so we shouldn't be creating interoperability among spec. deviations (and future compatibility requirements) unless we actually decide we want those deviations to be part of the standard language.

Waldemar's observation may well be correct for ES<=3. He would know, and if that was the intent then I can see how the spec. could be read in that manner. But for ES5 we rewrote that portion of the specification and introduced the concept of IdentifierName as a lexical category that includes both ReservedWord and Identifier and all the escape and canonicalization language was applied to IdentifierName rather than Identifier. This was all intentional. We certainly didn't expect true and tru\u0065 to be recognized as different identifier names in newly allowed contexts such as:

obj.true == obj.tru\u0065

I'm pretty sure that no reviewers brought up issues related to a ES3 interpretation of unicode escapes as keyword escapes.

At this point I think we need to do two things:

  1. Understand the actual browser interop situation. For example, do all major browsers accept: var tru\u0065;
  2. Within the constraints of 1) decide what we actually want to specify. Do we want console.log(fals\u0065) to print "false" or "undefined"?
  3. For ES6 we have to decide how {0065} fits in.
# Peter van der Zee (13 years ago)

On Thu, Apr 12, 2012 at 6:13 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:

At this point I think we need to do two things:

Add a third to that, because I don't think Gaz was talking about unicode escapes ("Haha nice try"). I'm still curious to the answer :)

# Brendan Eich (13 years ago)

Lasse Reichstein wrote:

Is this a deliberate Mozilla change

This is a hold-over from the past. It dates from ES4 days when the draft spec in TC39 proposed unreserving keywords not only after . in expressions and before : in object literal property assignments, but also after 'function'.

We have a bug on this: bugzilla.mozilla.org/show_bug.cgi?id=638667. In it you'll see comments from dherman and me last year trying to hold off on fixing the bug, in case Harmony adopts this proposal. If TC39 can decisively reject it, we'll fix the bug. Maybe we should just fix the bug anyway but I suspect we'll break some Mozilla-only code out there, so this won't happen quickly.

# gaz Heyes (13 years ago)

On 12 April 2012 17:36, Peter van der Zee <ecma at qfox.nl> wrote:

Add a third to that, because I don't think Gaz was talking about unicode escapes ("Haha nice try"). I'm still curious to the answer :)

The answer doesn't involved unicode escapes and I was asked not to post it because someone is still struggling to solve it :) I will post the answer later

# Norbert Lindenberg (13 years ago)

On Apr 12, 2012, at 9:13 , Allen Wirfs-Brock wrote:

At this point I think we need to do two things:

  1. Understand the actual browser interop situation. For example, do all major browsers accept: var tru\u0065;
  2. Within the constraints of 1) decide what we actually want to specify. Do we want console.log(fals\u0065) to print "false" or "undefined"?
  3. For ES6 we have to decide how {0065} fits in.

I think \u{0065} should behave exactly like \u0065 wherever it's syntactically allowed. It should be just a new notation; not a way to add or remove capabilities.

Norbert

# Brendan Eich (13 years ago)

Norbert Lindenberg wrote:

On Apr 12, 2012, at 9:13 , Allen Wirfs-Brock wrote:

At this point I think we need to do two things:

  1. Understand the actual browser interop situation. For example, do all major browsers accept: var tru\u0065;
  2. Within the constraints of 1) decide what we actually want to specify. Do we want console.log(fals\u0065) to print "false" or "undefined"?
  3. For ES6 we have to decide how {0065} fits in.

I think \u{0065} should behave exactly like \u0065 wherever it's syntactically allowed. It should be just a new notation; not a way to add or remove capabilities.

+1

# Brendan Eich (13 years ago)

Allen Wirfs-Brock wrote:

Floating around this area (in Mathias' blog post and Andreas' bug report, etc)) there are references to wiki.whatwg.org/wiki/Web_ECMAScript#Identifiers . It should be used justify any particular interpretation of the ES specification.

Missing "not" after "should" in last sentence.

# Allen Wirfs-Brock (13 years ago)

indeed!

# Brendan Eich (13 years ago)

Allen Wirfs-Brock wrote:

  1. Understand the actual browser interop situation. For example, do all major browsers accept: var tru\u0065;

SpiderMonkey shell:

js> var tru\u0065;

typein:1: SyntaxError: missing variable name: typein:1: var tru\u0065; typein:1: ....^

It looks like Carakan (Opera), JSC and V8 allow this. I can't test IE.

  1. Within the constraints of 1) decide what we actually want to specify. Do we want console.log(fals\u0065) to print "false" or "undefined"?

Carakan, JSC and V8 alert "undefined".

Anyone have IE results?

Looks like SpiderMonkey implemented ES5 not ES3, probably accidentally and ahead of time.

# Domenic Denicola (13 years ago)

var tru\u0065; => "Expected identifier" error in IE9.

console.log(fals\u0065) => "Syntax error" in IE9.

Can test IE10 when I get home from work.

# Brendan Eich (13 years ago)

Yes! IE and Firefox agree! :-P

I'm not suggesting "we" win, just glad not to be all alone on this one. ;-) Thanks for testing.

Allen, your thoughts?

# Allen Wirfs-Brock (13 years ago)

On Apr 12, 2012, at 10:51 AM, Brendan Eich wrote:

Yes! IE and Firefox agree! :-P

I'm not suggesting "we" win, just glad not to be all alone on this one. ;-) Thanks for testing.

Allen, your thoughts?

The IE9 console.log syntax error (I see it too) seem like a bug under any interpretation of the ES5.1 spec. My second test case actually isn't very good. console.log(fals\u0065) is actually a reference error in chrome and safari. This is the expected behavior when referencing an undeclared variable. So they are also de-keywordizing in that context. FF alerts "false" so it it interpreting the fals\u0065 in this context as the keyword and not as an Identifier.

So, FF (>= 4??) and IE9 don't seem to support unicode escape based de-keywordization and the web doesn't appear to have collapsed. That seems like a good indication that this isn't a major interp. concern and we can think about what we want such unicode escapes to mean rather than being forced to adopt something.

Personally, I think the de-keywordization interpretation is pretty ugly. It is taking something (unicode escapes) that presumably exist for specific purpose (a way to insert arbitrary Unicode code units into source text) and loads a secondary semantics upon them. I think that ES5 has already covered the important use cases for contextual non-keyword interpretation of reserved words. If we want to allow declarations that create bindings for reserved words (not something I favor) then we should address that head-on rather than via a ugly backdoor.

I think we should stick with the ES5 intent (Unicode escapes don't change the meaning of an IdentiferName, including keywords) and possibly clarify the Es6 spec. language to make this intent even clearer.

# Brendan Eich (13 years ago)

Allen Wirfs-Brock wrote:

The IE9 console.log syntax error (I see it too) seem like a bug under any interpretation of the ES5.1 spec. My second test case actually isn't very good. console.log(fals\u0065) is actually a reference error in chrome and safari. This is the expected behavior when referencing an undeclared variable. So they are also de-keywordizing in that context.

Try running with 'var fals\u0065;' prepended -- have to test both ways.

# Allen Wirfs-Brock (13 years ago)

On Apr 12, 2012, at 12:23 PM, Brendan Eich wrote:

Allen Wirfs-Brock wrote:

The IE9 console.log syntax error (I see it too) seem like a bug under any interpretation of the ES5.1 spec. My second test case actually isn't very good. console.log(fals\u0065) is actually a reference error in chrome and safari. This is the expected behavior when referencing an undeclared variable. So they are also de-keywordizing in that context.

Try running with 'var fals\u0065;' prepended -- have to test both ways.

var fals\u0065; console.log(fals\u0065); var fals\u0065; console.log(fals\u0065); var fals\u0065; console.log(fals\u0065);

Right chrome and safari log "undefined" in that case. FF and IE9 syntax error out on the var declaration.

# Luke Hoban (13 years ago)

So, FF (>= 4??) and IE9 don't seem to support unicode escape based de-keywordization and the web doesn't appear to have collapsed. That seems like a good indication that this isn't a major interp. concern and we can think about what we want such unicode escapes to mean rather than being forced to adopt something.

Personally, I think the de-keywordization interpretation is pretty ugly. It is taking something (unicode escapes) that presumably exist for specific purpose (a way to insert arbitrary Unicode code units into source text) and loads a secondary semantics upon them. I think that ES5 has already covered the important use cases for contextual non-keyword interpretation of reserved words. If we want to allow declarations that create bindings for reserved words (not something I favor) then we should address that head-on rather than via a ugly backdoor.

I think we should stick with the ES5 intent (Unicode escapes don't change the meaning of an IdentiferName, including keywords) and possibly clarify the Es6 spec. language to make this intent even clearer.

+1. Having Unicode escapes have no impact on the interpretation of an IdentifierName seems like a simpler model for the language, and the one that the ES5 spec text currently suggests. FWIW - I tested IE8 as well, and it also doesn't support Unicode escape de-keywordization, so I suspect this behavior has been around in browsers for quite a while.

Luke

# Domenic Denicola (13 years ago)

IE10 (Windows 8 Consumer Preview edition):

var tru\u0065; => "The use of a keyword for an identifier is invalid"

console.log(fals\u0065) => "Syntax error"

So same thing but better error message for the former case.

# Lasse Reichstein (13 years ago)

On Thu, Apr 12, 2012 at 4:11 PM, gaz Heyes <gazheyes at gmail.com> wrote:

On 12 April 2012 14:51, Lasse Reichstein <reichsteinatwork at gmail.com> wrote:

On Thu, Apr 12, 2012 at 2:58 PM, gaz Heyes <gazheyes at gmail.com> wrote:

function true(){alert('Call me');};

Is this a deliberate Mozilla change, or just a bug ("true" being a keyword and not valid as a function name in plain ECMAScript)?

And, btw,  /* MY CODE */  tru\u0065();

Haha nice try even with unicode escapes it still refers to "true" the boolean not the function.

I guess that depends on the version. I was testing in Firefox 9.0.1, and it runs your function.

In any case, the example is invalid ECMAScript, and I expect it to be fixed eventually (someone linked the Mozilla bug).

The current ES5 spec (and ES3 too) is ... vague ... on the meaning of tru\u0065, which explains the different implementations, but in order to "not break the web" the most common meaning has been to make it an IdentifierName but not a keyword. I.e., only "true" can be the keyword, but "tru\u0065" can be used as an identifier. I know I have implemented that to match Safari and Firefox, where my personal preference would be to throw a syntax error :).

# gaz Heyes (13 years ago)

On 13 April 2012 08:38, Lasse Reichstein <reichsteinatwork at gmail.com> wrote:

I guess that depends on the version. I was testing in Firefox 9.0.1, and it runs your function.

Ah I'm testing on FF11 if it works on your version then it's a valid answer :)

# Lasse Reichstein (13 years ago)

On Thu, Apr 12, 2012 at 8:53 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:

I think we should stick with the ES5 intent (Unicode escapes don't change the meaning of an IdentiferName, including keywords) and possibly clarify the Es6 spec. language to make this intent even clearer.

I.e., tru\u0065 is an IdentifierName, but neither an Identifier nor the "true" keyword. If so, I agree to that.

It would lexically parse as an IdentifierName, so there is no problem there (there would be in ES3 because it couldn't lexically parse as anything), and since "var tru\u0065" requires an Identifier, it's a syntactic parse error.

(And since unescaped keywords are valid IdentifierNames, you won't ever need escapes to make something valid that wouldn't otherwise be).

# gaz Heyes (13 years ago)

Ok here is my solution:

with(arguments.callee)function::'true'

So initially I thought the with statement was required to switch the context of "function::" but this also worked: with(1+1)function::'true'

However this doesn't work on Firefox 11: function::'true'

So what I think happens is Firefox looks for the true function in the window object then can't find it so falls back to the parent object with is the current anon function.

It can also be called using eval as eval is in the current scope: eval("function::'true'");

I guess the shortest you can possibly make it is: with(1)function::true()

# Wes Garland (13 years ago)

On 12 April 2012 15:37, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:

Right chrome and safari log "undefined" in that case. FF and IE9 syntax error out on the var declaration.

As long as we're exploring web compat, here's a historical view of SpiderMonkey behaviour --

JS 1.8.5 (~ Firefox 4) treats fals\u0065 as a valid identifier that is distinct from false. Same for JS 1.7 (~ Firefox 3) Same for JS 1.6 (~ Firefox 2) Same for JS 1.5 (ES-3) JS 1.4.1 does not allow unicode escapes in identifiers

# Brendan Eich (13 years ago)

Latest SpiderMonkey allows just

!function(){

function true(){print('Call me');};

function::true();

}();

as the solution. This shows extensions from E4X (namespaces, extended with the built-in 'function::' magic) and ES4 (allowing reserved identifiers after 'function').

Extensions are allowed by Clause 16 of ECMA-262. But perhaps there's an explicit prohibition on one or both of these?

Anyway they are demons from the second age, and they're going away.

# Brendan Eich (13 years ago)

Some time after Firefox 4, a fix went in so we match ES5:

js> fals\u0065

false js>

# Andreas Rossberg (13 years ago)

On 13 April 2012 16:47, Brendan Eich <brendan at mozilla.org> wrote:

Some time after Firefox 4, a fix went in so we match ES5:

js> fals\u0065 false js>

Hm, I still don't quite see where ES5 would specify this behaviour. The relevant bits I can find are:

  • In 5.1.6: "Terminal symbols of the lexical, RegExp, and numeric string grammars, and some of the terminal symbols of the other grammars, are shown in fixed width font, both in the productions of the grammars and throughout this specification whenever the text directly refers to such a terminal symbol. These are to appear in a program exactly as written."

  • In 7.8.2, the 'false' literal is defined in the aforementioned fixed width font.

  • In 7.6, the grammar of identifiers is given to allow unicode escapes, but excludes ReservedWords, which in turn include the aforementioned literals (in their verbatim form!).

  • Also in 7.6, the spec says: "A UnicodeEscapeSequence cannot be used to put a character into an IdentifierName that would otherwise be illegal. In other words, if a \ UnicodeEscapeSequence sequence were replaced by its UnicodeEscapeSequence's CV, the result must still be a valid IdentifierName that has the exact same sequence of characters as the original IdentifierName."

  • Going on, the spec says "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."

From the first 3 points I conclude that fals\u0065 is not the 'false' literal. It would be an identifier if it wasn't for the 4th point. Consequently, the token fals\u0065 is neither a literal nor an identifier!

The last point merely seems to be talking about "interpretation" of tokens that have already been syntactically classified as identifiers. I.e. it does not turn fals\u0065 into a literal again, it only results in f\u0065 denoting the same identifier as \u0066e.

In any case, this should really be clarified.

# Allen Wirfs-Brock (13 years ago)

On Apr 13, 2012, at 8:19 AM, Andreas Rossberg wrote:

On 13 April 2012 16:47, Brendan Eich <brendan at mozilla.org> wrote:

Some time after Firefox 4, a fix went in so we match ES5:

js> fals\u0065 false js>

Hm, I still don't quite see where ES5 would specify this behaviour. The relevant bits I can find are:

  • In 5.1.6: "Terminal symbols of the lexical, RegExp, and numeric string grammars, and some of the terminal symbols of the other grammars, are shown in fixed width font, both in the productions of the grammars and throughout this specification whenever the text directly refers to such a terminal symbol. These are to appear in a program exactly as written."

  • In 7.8.2, the 'false' literal is defined in the aforementioned fixed width font.

  • In 7.6, the grammar of identifiers is given to allow unicode escapes, but excludes ReservedWords, which in turn include the aforementioned literals (in their verbatim form!).

7.6 also provides the grammar for IdentifierName and allows for unicode escapes to appear within them.

  • Also in 7.6, the spec says: "A UnicodeEscapeSequence cannot be used to put a character into an IdentifierName that would otherwise be illegal. In other words, if a \ UnicodeEscapeSequence sequence were replaced by its UnicodeEscapeSequence's CV, the result must still be a valid IdentifierName that has the exact same sequence of characters as the original IdentifierName."

  • Going on, the spec says "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."

The history for the insertion of that sentence is given in es3.1:es5_candidate_errata_june_17.pdf The use of "Identifier" (rather than "IdentifierName" was in the feedback that seeded the change). It looks to me like the editor should have replaced "Identifier" with 'IdentifierName" when he added that sentence. There was certainly no intent that {false: 0} and {fals\u0065: 0} would produce objects whose sole own properties had different keys.

From the first 3 points I conclude that fals\u0065 is not the 'false' literal. It would be an identifier if it wasn't for the 4th point. Consequently, the token fals\u0065 is neither a literal nor an identifier!

The last point merely seems to be talking about "interpretation" of tokens that have already been syntactically classified as identifiers. I.e. it does not turn fals\u0065 into a literal again, it only results in f\u0065 denoting the same identifier as \u0066e.

In any case, this should really be clarified.

I agree.

The bigger point is that we have some divergence among implementations. That gives us space to decide what we really want and then clarify it.

I'ved proposed that we don't want fals\u0065 to be treated as an Identifier. It is still a ReservedWord even though it is written using a unicode escape.

# Allen Wirfs-Brock (13 years ago)

On Apr 13, 2012, at 8:19 AM, Andreas Rossberg wrote:

  • Going on, the spec says "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."

Looking carefully at the ES5.1 spec. I also notice that both identifier(s) and Identifier (italic) are used in this section. Its something else that probably need to be cleaned-up to clarify the meaning.