`this` binding incorrect for `setTimeouf(..)` and `setInterval(..)`

[getify]

In browsers, this code (however inadvisable it may be, it's still valid and spec correct) behaves as expected, which is that the interval is stopped after 5 seconds of printing "Hello World":

intv = setInterval(function(){
   console.log("Hello World");
},1000);

// elsewhere in the code base
setTimeout(function() {
   clearInterval(this.intv);
},5000);

But if you try the same code in node (0.10.29), the interval is never cleared, so the "Hello World" printing keeps going forever.

The problem comes down to the this binding in the underlying function calls.

According to the HTML5 spec, 6.4: Timers, and specifically 6.4.1: timer initialization steps, the this binding should be the window object (technically the "window-proxy") for normal apps, or the worker-global-scope in the case of web workers.

One could take that as a pretty strong precedent that the this binding should always be the appropriate hosting environment's global. But in node.js, it's not, it's some other object that's apparently related to the timer instance itself.

I have some real-world code using timers that works fine in a browser but is breaking when I port it to node, and it turns out this this binding issue is the direct cause.

The above code can be changed (without rearchitecting to use IIFE/module closures, etc), but it's uglier and less desirable:

intv = setInterval(function(){
console.log("Hello World");
},1000);

// elsewhere in the code base
setTimeout(function() {
var g = typeof window !== "undefined" ? window : typeof global !== "undefined" ? global : {};
clearInterval(g.intv);
},5000);

[Edit: I'm striking out the above note/code because it detracts my overall point and confuses the issue. sorry about that.]

---

I know the behavior of setTimeout(..) is controlled by HTML spec, not ES, and I know node isn't HTML, but with respect to certain on-top-of-or-related-to-ES touch points, the HTML spec takes a lot of care in doing sensible things, such as an explicit predictable this binding here, and it's frustrating that node.js diverges here.

Can we consider changing this behavior to follow the spec precedent?

[getify]

And btw, I have two other sets of code which themselves have nothing to do with setTimeout(..), nor do they have anything to do with properties on the global object. They just deal with detecting this binding inside of functions and responding accordingly. But if you take those lib pieces and happen to use them directly with a timer in node, my lib code breaks for the same reasons above.

So this issue is not about whether it's a good idea to use properties on the global object or not, it's purely about whether timers in node should diverge from timers in the browser (and other JS environments, btw) with respect to this binding.

[dshaw]

If you're intentionally attaching to global, why not do so explicitly in the original assignment of intv?

[getify]

@dshaw please see my follow up comment. I chose this timer example because it's easy to illustrate the problem, not because it's the real code having the problem. The real code having the problem relies on detecting the this binding of any given function call, not about assigning or retrieving properties from that global object.

[jcemer]

I notice that the Node implementation do not respect the nested call time limit.
I know this is another issue. But it just to show other divergence between the spec and implementation.

[davglass]

I've seen this break old code too, we just refactored it in the end but I see how this is a bad thing and should probably be fixed.

[domenic]

In general Node's setTimeout and setInterval are nowhere near the browser specs in various ways, so I am not sure hoping for convergence is right. That said maybe patching holes on a piecewise basis is fine as long as they don't break existing code.

[mgol]

How do they differ (and why)? I wonder why Node didn't reuse browser specs
here...

Michał Gołębiowski

[simonkcleung]

setTimeout binds the timer object to "this" object in the callback.

First of all, in most cases, the execution environment in Node is a "module", so when
var k=2;
exports.k=3;
console.log(k);//2
console.log(this.k);//3
This is the difference between browser and node.

Making reference to "window" object in browser is easy becasuse it is a global object.
But in Node, setTimeout/setInterval does no way to get the "exports" object nor the execution environment of the module.

[getify]

But AFAICT, all code always has access to the global object, even inside of modules. The most consistent thing would be to always attach to the global, regardless of where in node the code is running.

[mgol]

It's not only about the global; in strict mode the binding is to undefined which is also not satisfied in Node.

[getify]

No, the html spec calls for it to be window always, regardless of strict-mode. Try it yourself. :)

setTimeout(function(){ "use strict"; console.log(this === window); },100);

If the spec were to call for the window-or-undefined binding (per strict-mode), it would need to set the this to undefined or null, which in strict-mode would get left alone (passed-thru), and in non-strict-mode, would get overriden to be window. But since that's not what the spec calls for, it's kinda moot. :)

[mgol]

Hah, interesting. I assumed it follows call/apply semantics, thanks for
clarification. :)

[simonkcleung]

I dont know why node bind the timer object as this, but I want to explain that binding the global to this is not what you expected.

var intv;
(function(){
var intv = setInterval(function(){
   console.log("Hello World");
},1000);

// elsewhere in the code base
setTimeout(function() {
   clearInterval(this.intv);
},5000);
})();

In browser, above doesnt work. Node is in same situation. The code runs in local scope inside the module. All the variables are not visible from global.

[getify]

@simonkcleung
Please read above. My example was to illustrate the problem, not the actual affected code itself. I'm not advocating attaching/retrieving properties on the global object. Nevertheless, I have valid code that detects this === global and behaves accordingly, and that code works in all browsers, but fails in node.

PS. I'm well aware that var inside a function doesn't attach to the global. But that's a totally orthagonal/moot point. You'll notice that my code example didn't use var at all. That was on purpose so this sort of distraction wasn't argued about. :)

[vkurchatkin]

@getify can you provide a real life example?