"use strict" VS setTimeout

Boris Zbarsky bzbarsky at mit.edu
Mon Sep 8 07:41:02 PDT 2014


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


More information about the es-discuss mailing list