Re: Unicode non-character being treat as space on Firefox/Chrome

On 25 May 2017 at 17:02, Mark S. Miller wrote: > Allen, I'm very glad to hear that it is unambiguous after all. > Gareth, could you file bugs against the non-conforming browsers? Thanks for > finding this! > Yeah sure I'll file the bugs now.

Re: Unicode non-character being treat as space on Firefox/Chrome

Allen, I'm very glad to hear that it is unambiguous after all. Gareth, could you file bugs against the non-conforming browsers? Thanks for finding this! On Thu, May 25, 2017 at 8:58 AM, Allen Wirfs-Brock wrote: > clause 10.1: > > ECMAScript code is expressed using

Re: Unicode non-character being treat as space on Firefox/Chrome

clause 10.1: ECMAScript code is expressed using Unicode. ECMAScript source text is a sequence of code points. All Unicode code point values from U+ to U+10, including surrogate code points, may occur in source text where permitted by the ECMAScript grammars.

Re: Unicode non-character being treat as space on Firefox/Chrome

Subject: Re: Unicode non-character being treat as space on Firefox/Chrome On 25 May 2017 at 14:04, Mark S. Miller <erig...@google.com<mailto:erig...@google.com>> wrote: What is the relevant EcmaScript standards text that would delegate to this? Even if Unicode implies an undefined

Re: Unicode non-character being treat as space on Firefox/Chrome

On 25 May 2017 at 14:04, Mark S. Miller wrote: > What is the relevant EcmaScript standards text that would delegate to > this? Even if Unicode implies an undefined case, EcmaScript should not. If > EcmaScript behavior for such cases is undefined, we should define it. >

Re: Unicode non-character being treat as space on Firefox/Chrome

I believe that Unicode specification make it undefined behaviour. In effect, noncharacters can be thought of as application-internal private-use code points. Unlike the private-use characters discussed in Section 16.5, Private-Use Characters, which are assigned characters and which are intended

Unicode non-character being treat as space on Firefox/Chrome

Hi all Not sure if this is a bug or not. Non-character is being treated as a space even though it's not defined as one. Edge and Safari treat it as an invalid character. ```javascript �alert�(1)� ``` In case the characters get mangled: ```javascript

for-of in Firefox

Does Firefox not yet do the one binding per loop iteration? I would have expected the output `0` in the following code. ```js let arr = []; for (let i of [0, 1, 2]) { arr.push(() = i); } console.log(arr[0]()); // 2 ``` -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de

Re: for-of in Firefox

The implementation predates ES6 let: https://bugzilla.mozilla.org/show_bug.cgi?id=950547 Rick On Sat, Jul 26, 2014 at 1:11 PM, Axel Rauschmayer a...@rauschma.de wrote: Does Firefox not yet do the one binding per loop iteration? I would have expected the output `0` in the following code

Firefox: for-of and objects

Sorry, slightly off-topic: Does Firefox already have @iter.items (etc.)? Or is there something similar one could use to iterate over [key, value] pairs for objects, via for-of? Thanks! Axel -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog

Re: Firefox: for-of and objects

On Thu, Oct 25, 2012 at 1:24 PM, Axel Rauschmayer a...@rauschma.de wrote: Sorry, slightly off-topic: Does Firefox already have @iter.items (etc.)? Or is there something similar one could use to iterate over [key, value] pairs for objects, via for-of? You can use Iterator, e.g.: for ([key

Re: Firefox: for-of and objects

On Thu, Oct 25, 2012 at 6:24 AM, Axel Rauschmayer a...@rauschma.de wrote: Sorry, slightly off-topic: Does Firefox already have @iter.items (etc.)? Or is there something similar one could use to iterate over [key, value] pairs for objects, via for-of? Unfortunately Iterator does do that, but I

Re: Firefox: for-of and objects

On Thu, Oct 25, 2012 at 11:50 AM, Jason Orendorff jason.orendo...@gmail.com wrote: On Thu, Oct 25, 2012 at 6:24 AM, Axel Rauschmayer a...@rauschma.de wrote: Sorry, slightly off-topic: Does Firefox already have @iter.items (etc.)? Or is there something similar one could use to iterate over [key

Re: Fun impossible Firefox JS challenge

, 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

Re: Fun impossible Firefox JS challenge

On 13 April 2012 08:38, Lasse Reichstein reichsteinatw...@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

Re: Fun impossible Firefox JS challenge

On Thu, Apr 12, 2012 at 8:53 PM, Allen Wirfs-Brock al...@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.,

Re: Fun impossible Firefox JS challenge

On 12 April 2012 15:37, Allen Wirfs-Brock al...@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

Re: Fun impossible Firefox JS challenge

Some time after Firefox 4, a fix went in so we match ES5: js fals\u0065 false js /be Wes Garland wrote: On 12 April 2012 15:37, Allen Wirfs-Brock al...@wirfs-brock.com mailto:al...@wirfs-brock.com wrote: Right chrome and safari log undefined in that case. FF and IE9 syntax error

Re: Fun impossible Firefox JS challenge

On 13 April 2012 16:47, Brendan Eich bren...@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

Re: Fun impossible Firefox JS challenge

On Apr 13, 2012, at 8:19 AM, Andreas Rossberg wrote: On 13 April 2012 16:47, Brendan Eich bren...@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

Re: Fun impossible Firefox JS challenge

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

Fun impossible Firefox JS challenge

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

Re: Fun impossible Firefox JS challenge

On Thu, Apr 12, 2012 at 2:58 PM, gaz Heyes gazhe...@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(); /L

Re: Fun impossible Firefox JS challenge

On 12 April 2012 14:51, Lasse Reichstein reichsteinatw...@gmail.com wrote: On Thu, Apr 12, 2012 at 2:58 PM, gaz Heyes gazhe...@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

Re: Fun impossible Firefox JS challenge

On 12 April 2012 16:11, gaz Heyes gazhe...@gmail.com wrote: On 12 April 2012 14:51, Lasse Reichstein reichsteinatw...@gmail.com wrote: On Thu, Apr 12, 2012 at 2:58 PM, gaz Heyes gazhe...@gmail.com wrote: function true(){alert('Call me');}; Is this a deliberate Mozilla change, or just a bug

Re: Fun impossible Firefox JS challenge

On 12 April 2012 15:12, Andreas Rossberg rossb...@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 ___ es-discuss

Re: Fun impossible Firefox JS challenge

On Thu, Apr 12, 2012 at 4:12 PM, Andreas Rossberg rossb...@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

Re: Fun impossible Firefox JS challenge

!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` On Thu, Apr 12, 2012 at 9:27 AM, Peter van der Zee e...@qfox.nl

Re: Fun impossible Firefox JS challenge

On 12 April 2012 15:34, crypticswarm crypticsw...@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

Re: Fun impossible Firefox JS challenge

(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

Re: Fun impossible Firefox JS challenge

On 12 April 2012 16:27, Peter van der Zee e...@qfox.nl wrote: On Thu, Apr 12, 2012 at 4:12 PM, Andreas Rossberg rossb...@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.

Re: Fun impossible Firefox JS challenge

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:

RE: Fun impossible Firefox JS challenge

, April 12, 2012 11:06 To: Lasse Reichstein Cc: es-discuss Steen Subject: Re: Fun impossible Firefox JS challenge For those interested, Spidermonkey doesn’t handle the following correctly: function \u0074rue() { alert('PASS'); } \u0074rue(); function \u0074rue() { alert('PASS'); } tru

Re: Fun impossible Firefox JS challenge

On 12 April 2012 17:19, Domenic Denicola dome...@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. :) /Andreas

Re: Fun impossible Firefox JS challenge

On Apr 12, 2012, at 8:06 AM, Andreas Rossberg wrote: On 12 April 2012 16:27, Peter van der Zee e...@qfox.nl wrote: On Thu, Apr 12, 2012 at 4:12 PM, Andreas Rossberg rossb...@google.com wrote: Haha nice try even with unicode escapes it still refers to true the boolean not the function.

Re: Fun impossible Firefox JS challenge

On Thu, Apr 12, 2012 at 6:13 PM, Allen Wirfs-Brock al...@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 :) - peter

Re: Fun impossible Firefox JS challenge

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'.

Re: Fun impossible Firefox JS challenge

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.

Re: Fun impossible Firefox JS challenge

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

Re: Fun impossible Firefox JS challenge

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

Re: Fun impossible Firefox JS challenge

indeed! On Apr 12, 2012, at 10:19 AM, Brendan Eich wrote: Allen Wirfs-Brock wrote: Floating around this area (in Mathias' blog post and Andreas' bug report, etc)) there are references to http://wiki.whatwg.org/wiki/Web_ECMAScript#Identifiers . It should be used justify any particular

Re: Fun impossible Firefox JS challenge

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

RE: Fun impossible Firefox JS challenge

] Sent: Thursday, April 12, 2012 13:38 To: Allen Wirfs-Brock Cc: es-discuss Steen Subject: Re: Fun impossible Firefox JS challenge Allen Wirfs-Brock wrote: 1) Understand the actual browser interop situation. For example, do all major browsers accept: var tru\u0065; SpiderMonkey shell: js

Re: Fun impossible Firefox JS challenge

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? /be Domenic Denicola wrote: var tru\u0065; = Expected identifier error in IE9. console.log(fals\u0065) = Syntax error in IE9. Can test IE10

Re: Fun impossible Firefox JS challenge

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

Re: Fun impossible Firefox JS challenge

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

Re: Fun impossible Firefox JS challenge

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

RE: Fun impossible Firefox JS challenge

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

RE: Fun impossible Firefox JS challenge

-boun...@mozilla.org] On Behalf Of Domenic Denicola Sent: Thursday, April 12, 2012 13:49 To: Brendan Eich; Allen Wirfs-Brock Cc: es-discuss Steen Subject: RE: Fun impossible Firefox JS challenge var tru\u0065; = Expected identifier error in IE9. console.log(fals\u0065) = Syntax error in IE9. Can

Firefox/Chrome: {} + {} etc.

is a string, perform string concatenation. Hence not all of the following results in Firefox look OK to me: [16:33:50.214] [] + [] [16:33:50.217] // OK -- [16:33:56.098] {} + {} [16:33:56.099] NaN // Not OK -- [16:34:02.455] {} + [] [16:34:02.456] 0 // Not OK

Re: Firefox/Chrome: {} + {} etc.

returns an object which is thus discarded), then toString() Finally, as at least one operand is a string, perform string concatenation. Hence not all of the following results in Firefox look OK to me: [16:33:50.214] [] + [] [16:33:50.217] // OK -- [16:33:56.098

RE: Firefox/Chrome: {} + {} etc.

Rauschmayer Sent: Friday, January 27, 2012 8:21 AM To: es-discuss Subject: Re: Firefox/Chrome: {} + {} etc. Ah! Good call. And, as expected, wrapping the first operand in parens makes the problem go away. REPL input is tricky to parse correctly in JS, kind of between statements and expressions. On Jan

Re: Firefox/Chrome: {} + {} etc.

On Jan 27, 2012, at 8:38 AM, Luke Hoban wrote: JS REPLs tend to parse input as Program productions. Parsing {} + {} as a block followed by a unary expression is correct according to ES5 grammar for Program. IE behaves the same. It's not just in Program, it's any statement context.

Re: Firefox/Chrome: {} + {} etc.

JS REPLs tend to parse input as Program productions. Parsing {} + {} as a block followed by a unary expression is correct according to ES5 grammar for Program. IE behaves the same. It's not just in Program, it's any statement context. However, it is hard to actually observe

Re: ECMAScript.next features in Firefox?

On 25 December 2011 13:26, Axel Rauschmayer a...@rauschma.de wrote: Paul Irish did a code search for that: http://www.google.com/codesearch#W9JxUuHYyMg/trunk/src/flag-definitions.hq=harmony%20package:http://v8\.googlecode\.coml=109 To elaborate, the --harmony flag currently activates the

Confused by Firefox: own property with a descriptor not listed by getOwnPropertyNames()

I’m a bit confused by the following interaction on Firefox: Object.getOwnPropertyNames(new Error()) [] Object.getOwnPropertyDescriptor(new Error(), stack) {…} That does not make sense to me. Shouldn’t the property be either accessible in both cases or in neither case? -- Dr

ECMAScript.next features in Firefox?

Is there a list somewhere of ECMAScript.next features that have already been implemented in Firefox? Thanks! Axel -- Dr. Axel Rauschmayer a...@rauschma.de twitter.com/rauschma Home: rauschma.de Blog: 2ality.com ___ es-discuss mailing list es

Re: ECMAScript.next features in Firefox?

implemented in Firefox? Thanks! Axel -- Dr. Axel Rauschmayer a...@rauschma.de twitter.com/rauschma Home: rauschma.de Blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: ECMAScript.next features in Firefox?

the harmony flag? ( http://codereview.chromium.org/9008031 ) On Sun, Dec 25, 2011 at 9:31 AM, Axel Rauschmayer a...@rauschma.de wrote: Is there a list somewhere of ECMAScript.next features that have already been implemented in Firefox? Thanks! Axel -- Dr. Axel Rauschmayer