"use strict" VS setTimeout

Jasvir Nagra jasvir at gmail.com
Mon Sep 8 09:49:12 PDT 2014


On Mon, Sep 8, 2014 at 8:45 AM, Mark S. Miller <erights at google.com> wrote:

> On Mon, Sep 8, 2014 at 8:35 AM, Andrea Giammarchi <
> andrea.giammarchi at gmail.com> wrote:
>
>> Boris and Mark, I was talking about engines, already inevitably able to
>> distinguish strict from sloppy,
>>
>
> We have made great progress in JS better able to implement/emulate the
> APIs we expect browsers to provide. One of the design constraints on WebIDL
> is "can it be implemented in JS, perhaps by a proxy?" Exotic object
> behavior that cannot be implemented even by proxies is held with great
> suspicion, though some of this remains.
>
> So I would generally avoid having the engine observably make a test that
> JS can't do. Again, one of these remains as well: a magical sloppy.caller
> can't reveal a non-sloppy caller.
>
>
>
>> but in any case in JS is straight forward to know if you are under strict
>> directive or not.
>>
>> ```js
>> var isStrictAvailable = (function(){'use strict';return !this}());
>> var isThisStrict = isStrictAvailable && (function(){return !this}());
>> ```
>>
>
> That test only one's own lexical scope. It does not test a function value
> given to you across an API boundary.
>

Agreed. Can you say why this is a desirable property?  I ask mostly to
understand what the consequences are of some side-channel leak which allows
a caller to decide the strictness of a particular function (say via
toSource fr'instance) that it is calling - are there security consequences?


>
>
>> Btw, I laughed hard than I've should have on this:
>>
>> > "Now it just happens that Blink, IE and WebKit (or at least Safari)
>> have buggy requestAnimationFrame implementations."
>>
>> Best Regards
>>
>
> ;)
>
> Please do file bugs on these and post the links. Thanks.
>
>
>
>
>>
>> On Mon, Sep 8, 2014 at 3:41 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
>>
>>> On 9/8/14, 10:25 AM, Andrea Giammarchi wrote:
>>>
>>>> Apologies, now I see what you meant and I think option 2 would be
>>>> probably ideal. ES5+ engines can easily retrieve "strictness"
>>>>
>>>
>>> In script?  How?  (Again, clearly in the VM implementation I can do
>>> this.)
>>>
>>>  Going through the list of all properties it looks like at the end of the
>>>> day only things to improve/change are:
>>>>
>>>> requestAnimationFrame
>>>> setInterval
>>>> setTimeout
>>>>
>>>
>>> requestAnimationFrame doesn't have this problem.  See <
>>> http://www.w3.org/TR/animation-timing/#dfn-invoke-callbacks-algorithm>
>>> and the text about "callback this value" at <http://heycam.github.io/
>>> webidl/#es-invoking-callback-functions>: it defaults to undefined
>>> unless specified otherwise, and the requestAnimationFrame spec doesn't
>>> specify otherwise.  You can see a testcase for this behavior at
>>> http://jsfiddle.net/xpwr1ozx/
>>>
>>> Now it just happens that Blink, IE and WebKit (or at least Safari) have
>>> buggy requestAnimationFrame implementations.  Specifically, Blink and IE
>>> pass a Window as "this" (I didn't check which Window) and WebKit passes the
>>> function itself as "this" as far as I can tell(!).  Firefox follows the
>>> spec and passes undefined.  Please feel free to file bugs on the other
>>> implementations!
>>>
>>>  Although I have honestly no idea how to explain via W3C pages that JS
>>>> might be strict or not ... seems to me that "_strictness_" should be
>>>> outside the DOM knowledge so .... probably this should be part of ES
>>>> specification.
>>>>
>>>
>>> The normal way this would be done is that ES would expose an abstract
>>> operation that returns true or false for strictness of a function and then
>>> DOM would invoke that abstract operation.  Though obviously the DOM could
>>> just directly check the [[Strict]] internal slot too if there is no
>>> abstract operation defined for it.
>>>
>>> -Boris
>>>
>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140908/16cd3edf/attachment-0001.html>


More information about the es-discuss mailing list