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 <[email protected]> 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 <[email protected]> wrote: > >> On Mon, Sep 8, 2014 at 8:45 AM, Mark S. Miller <[email protected]> >> wrote: >> >>> On Mon, Sep 8, 2014 at 8:35 AM, Andrea Giammarchi < >>> [email protected]> 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 <[email protected]> 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 >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> > > > -- > Cheers, > --MarkM >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
