"use strict" VS setTimeout

Andrea Giammarchi andrea.giammarchi at gmail.com
Mon Sep 8 10:29:25 PDT 2014


so far I've managed to file Chromium and WebKit only:
https://code.google.com/p/chromium/issues/detail?id=411959
https://bugs.webkit.org/show_bug.cgi?id=136635

with IE I've had some trouble finding a "file a bug" link ...

Best Regards

On Mon, Sep 8, 2014 at 5:53 PM, Mark S. Miller <erights at google.com> wrote:

> No, this isn't an information disclosure or any other security issue. It
> is "only" a modularity issue.
>
>
>
> On Mon, Sep 8, 2014 at 9:49 AM, Jasvir Nagra <jasvir at gmail.com> wrote:
>
>> 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
>>>
>>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140908/2cc02056/attachment-0001.html>


More information about the es-discuss mailing list