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 > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
