"use strict" VS setTimeout

Garrett Smith dhtmlkitchen at gmail.com
Sun Sep 7 11:44:48 PDT 2014


On 9/7/14, Domenic Denicola <domenic at domenicdenicola.com> wrote:
> I don't understand why this is any more surprising than any other function
> that calls its callback with .call(something). It doesn't matter whether the
> callback is strict or not; .call(window), which is what the spec does, will
> override it.
>
> As far as I can see this issue has absolutely nothing to do with strict vs.
> sloppy.
>
I agree on that point; setTimeout passes the window to the callback as
the this value. But that has nothing to do with inheritance.

Method setTimeout uses the global object as the `this` value for the
callback function, much like addEventListener, etc, as does
`.call(window)` like you mentioned.

________________________________
> From: Andrea Giammarchi<mailto:andrea.giammarchi at gmail.com>
> Sent: 2014-09-07 19:14
> To: Mark Miller<mailto:erights at gmail.com>
> Cc: Mark S. Miller<mailto:erights at google.com>; es-discuss
> list<mailto:es-discuss at mozilla.org>
> Subject: Re: "use strict" VS setTimeout
>
> It feels to me also a vector that will happily pass all linters and code
> analyzers giving users a door to reach native context and start playing in
> there with everything else. I'm pretty sure you would agree on this too :)
>
> Please let us know if there's any follow up, it's probably easier/faster if
> some googler mention this issue to other googlers that are collaborating
> with WHATWG or W3C or both (or none)
>
> Thanks
>
> On Sun, Sep 7, 2014 at 7:11 PM, Mark Miller
> <erights at gmail.com<mailto:erights at gmail.com>> wrote:
> On Sun, Sep 7, 2014 at 11:07 AM, Andrea Giammarchi
> <andrea.giammarchi at gmail.com<mailto:andrea.giammarchi at gmail.com>> wrote:
> Yes Axel, that's how it works, this will show undefined indeed all over
>
> ```js
> (function () {
>   'use strict';
>   function g() {
>     console.log(this);
>   }
>   g(); // undefined
>   setTimeout(function () {
>     g(); // undefined
>   }, 0);
> }());
> ```
>
> or testing other use strict restrictions:
>
> ```js
> (function () {
>   'use strict';
>   setTimeout(function () {
>     argument.callee
>   }, 0);
> }());
> ```
>
> The strict behavior is preserved, it's not an opt-out, but the invoked
> function within setTimeout has the global context regardless it has been
> defined under the strict directive + regardless it defines itself as
> strict.
>
> Basically if you feel secure about "use strict" here you have a case that
> shows you shouldn't ... making one point of strict directive kinda
> broken/pointless.
>
> Agreed. I would remove only "kinda" from that statement ;).
>
>
>
> Regards
>
>
> On Sun, Sep 7, 2014 at 7:02 PM, Axel Rauschmayer
> <axel at rauschma.de<mailto:axel at rauschma.de>> wrote:
> On Sep 7, 2014, at 19:47 , Mark S. Miller
> <erights at google.com<mailto:erights at google.com>> wrote:
>
> On Sun, Sep 7, 2014 at 10:36 AM, Mathias Bynens
> <mathiasb at opera.com<mailto:mathiasb at opera.com>> wrote:
> On Sun, Sep 7, 2014 at 7:29 PM, Andrea Giammarchi
> <andrea.giammarchi at gmail.com<mailto:andrea.giammarchi at gmail.com>> wrote:
>> This looks like a potential problem when possible passed methods are not
>> bound + it looks inconsistent with *"use strict"* expectations.
>
> Yes. This looks like a typical screwup. Thanks for pointing it out.
>
> Interesting. Follow-up question: isn't strictness propagated lexically? That
> is, shouldn't the parameter of `setTimeout()` be strict even without being
> explicitly declared as such?
>
>
> --
>
>   Cheers,
>   --MarkM
>
>


-- 
Garrett
@xkit
ChordCycles.com
garretts.github.io


More information about the es-discuss mailing list