On 03/17/2015 11:37 AM, Boris Zbarsky wrote:
> It fails because the invalid function-in-block source gets desugared by
> SpiderMonkey like so (from your original mail) into valid JS:
>
> if (q) {
> var client1 = {on:function(){}};
> client1.on('close', onclose);
> var onclose = function onc
Thanks for both of the answers and in-depth explanations.
___
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
On 3/17/15 2:10 PM, obastemur wrote:
Still, considering the today's JavaScript usage, and this one is already
handled by an other browser(s)
In different ways, note.
And worse yet, as Jason said, websites do UA sniffing and depend on the
different ways that browsers handle this syntactic con
On Tuesday, March 17, 2015 at 3:26:52 PM UTC+1, Jason Orendorff wrote:
> It's not a bug, but it's a known ...situation.
>
> Function statements inside blocks are not a standard feature. They've had
> different behavior in different JS engines basically forever, and the last
> time we tried to chan
It's not a bug, but it's a known ...situation.
Function statements inside blocks are not a standard feature. They've had
different behavior in different JS engines basically forever, and the last
time we tried to change the behavior we gave up because it broke web sites.
If you tried that in stri
We've been chatting with Huabin on this issue last couple of days. My
experience with SpiderMonkey says the objects are GC'ed (as expected).
I'm wondering if there is something else happening. A known GC issue prior to
SM34? An extra note here is that Cocos2d-JS uses SM31 while JXcore with (SM3
The script below doesn't work (onclose is undefined) for both Firefox and
JXcore(SM):
var q = 1;
if (q) {
var client1 = {on:function(){}};
client1.on('close', onclose);
function onclose() {
console.log('dummy');
}
}
Interestingly it works without 'if scope':
var client1 = {on:fu
7 matches
Mail list logo
