W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2011

Re: Strict mode callbacks and setTimeout

From: Mark S. Miller <erights@google.com>
Date: Wed, 6 Jul 2011 14:36:48 -0700
Message-ID: <CABHxS9hy5b_3KO6matJD+JFcpUSXmSKVt-_OYOrc5vPgStQJeA@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Allen Wirfs-Brock <allen@wirfs-brock.com>, Luke Hoban <lukeh@microsoft.com>, "es5-discuss@mozilla.org" <es5-discuss@mozilla.org>, public-script-coord@w3.org
On Wed, Jul 6, 2011 at 2:33 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 7/6/11 5:22 PM, Mark S. Miller wrote:
>
>> On all the browsers I just tested,
>>
>> (1,setTimeout)(function(){'use strict'; alert('foo'); }, 0)
>>
>> alerts 'foo'.
>>
>
> So I suppose from the webidl point of view setTimeout is just a non-strict
> function?


Why? What breaks if webidl considers setTimeout to be a strict function?



>
>
>     This is true for non-strict-mode code already, right?  Or am I
>>    misunderstanding the problem?
>>
>> I think you are. For the specified HTML5 behavior, when a setTimeout
>> from frame X calls a non-strict callback from frame Y passing undefined
>> as the thisArg, it is the non-strict callback's [[Call]] method that
>> coerces the thisArg to Y's global object. Nothing requires X's
>> setTimeout to be able to figure out what Y's global object is.
>>
>
> Ah, ok.
>
>
>  Yes, this is the important legacy compat issue. We need to take a cross
>> browser survey.
>>
>>      What does the ES5 spec say about that case? (Probably nothing,
>>    since it assumes a unique global.)
>>
>>
>> Correct. But our intent moving forward is clearly towards a lexical
>> understanding of "which global".
>>
>
> Understood.
>
> -Boris
>



-- 
    Cheers,
    --MarkM
Received on Wednesday, 6 July 2011 21:37:13 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:04 UTC