You wrote itself the surprise, nobody wrote `.call(window)` or
`.bind(window)` so you receive implicitly a global context in a place you
were not expecting it.
Think about object methods instead of that one shot but also think that
under "use strict" `.call(null)` whould not bring the global context in
there.
Accordingly, this feels like some sort of W3C specs misalignment with JS
land and the fact at least 2 of us think it's surprising to receive that
context automagically in non bound functions maybe indicates something does
not feel right, no matter what's written in that specific part of timers
specs (also non respected in nodejs land)
But here I go back to the utopia I've already mentioned on putting everyone
together to fix this, and I'm fine if it won't change but it's good to know
that "use strict" could implicitly fail when the DOM is involved.
Regards
On Sun, Sep 7, 2014 at 7:27 PM, Domenic Denicola <
dome...@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.
> ------------------------------
> From: Andrea Giammarchi <andrea.giammar...@gmail.com>
> Sent: 2014-09-07 19:14
> To: Mark Miller <erig...@gmail.com>
> Cc: Mark S. Miller <erig...@google.com>; es-discuss list
> <es-discuss@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 <erig...@gmail.com> wrote:
>
>> On Sun, Sep 7, 2014 at 11:07 AM, Andrea Giammarchi <
>> andrea.giammar...@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 <a...@rauschma.de>
>>> wrote:
>>>
>>>> On Sep 7, 2014, at 19:47 , Mark S. Miller <erig...@google.com> wrote:
>>>>
>>>> On Sun, Sep 7, 2014 at 10:36 AM, Mathias Bynens <mathi...@opera.com>
>>>> wrote:
>>>>
>>>>> On Sun, Sep 7, 2014 at 7:29 PM, Andrea Giammarchi
>>>>> <andrea.giammar...@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
>>
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
