Re: Why are global variables *non-deletable* properties of the global object?
Brendan Eich wrote: > Works correctly (true, false, 43) in Firefox 3 (try it, you'll like > it!). > > That looks like a Firefox 2 bug, probably to do with "inner and outer > windows". Don't ask (security requirement of the DOM level 0, > implemented similarly in IE and Firefox, IIRC coming soon to Webkit, > very probably in Opera; but thanks for pointing this out!). (true, false, 43) in Opera 9.5 Chris ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Why are global variables *non-deletable* properties of the global object?
On Jun 19, 2008, at 11:20 PM, Brendan Eich wrote: > It's just a bug in Firefox 2. The bug was https://bugzilla.mozilla.org/show_bug.cgi?id=369259 in case anyone is interested. /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: const formal parameters?
On Jun 19, 2008, at 8:17 PM, Mark S. Miller wrote: > > So long as it parses, that would allow code to version sniff and > adapt, with conditionals, to different execution environments. That's > why we're using the "parses on 3/4 browsers" criterion. (Thanks > Maciej, I think) I think my only involvement in the 3/4 rule was asking what it actually meant. I'm not sure who deserves credit for originating it. Regards, Maciej ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Why are global variables *non-deletable* properties of the global object?
On Jun 19, 2008, at 11:20 PM, Brendan Eich wrote:
> On Jun 19, 2008, at 8:40 PM, Mark S. Miller wrote:
>
>>> Try putting this in a Firefox address toolbar:
>>>
>>> javascript:alert('foo' in window); var foo = 42; alert(delete foo);
>>> alert(foo)
>>>
>>> You will get true (because the var binding -- not initialization
>>> -- is
>>> hoisted to the top of the program, right after the javascript:),
>>> false
>>> (because var makes a DontDelete binding outside of eval), and 42.
>>
>> I did. Thanks for suggesting that experiment. But given the above
>> behavior, I don't understand
>>
>> javascript:alert('foo' in window); var foo = 42; window.foo = 43;
>> alert(delete window.foo); alert(window.foo)
>>
>> I get true, true, undefined.
>
> Works correctly (true, false, 43) in Firefox 3 (try it, you'll like
> it!).
Also works correctly in Safari 3.1 and the Safari 4 Developer Preview
(which implements split window support).
Regards,
Maciej
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: How can eval code not have a calling context?
On Jun 19, 2008, at 8:20 PM, Mark S. Miller wrote:
>> Some browsers support indirect eval, allowing this:
>>
>> setTimeout(eval, 0, "alert('hi mom')")
>>
>> The window used is the one in which setTimeout was found along the
>> scope
>> chain, so
>>
>> myFrame.setTimeout(eval, 0, "alert(x)")
>>
>> should show myFrame.x, not the calling frame or window's x.
>>
>> This is not something patched Firefox major versions support.
>
>
> Thanks, this was very clarifying. Which of these cases would ES4
> consider to be uses of the eval operator, and which of the eval
> function?
No eval operator calls above ;-). No function calls to foo.eval where
foo is a window either. These are indirect eval calls via setTimeout.
We ban them in Firefox precisely because there is no calling context,
so we don't know the trust label of the caller.
/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
