- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Mon, 23 Sep 2013 12:39:38 -0400
- To: "public-script-coord@w3.org" <public-script-coord@w3.org>
Consider this testcase: test.html: <!DOCTYPE html> <html> <iframe src="test2.html"></iframe> <script> window.onload = function() { frames[0].addEventListener.call(undefined, "click", function(e) { alert("clicked. This: " + e.currentTarget.type) }); } var type = 'Parent'; </script> Or click me. </html> test2.html: <!DOCTYPE html> <html> <script>var type = 'subframe'</script>Click me </html> Which window is the click listener added to? That is, which global is the undefined thisArg coerced to? In Firefox (recent nightly), Chrome (recent dev build), and IE10 the answer is the subframe's global. In Safari 6, Opera (12.16), and a WebKit nightly, the answer is the parent page's global. In IE9, the .call() throws an exception about the this value not being an object, as far as I can tell. But of course bareword addEventListener() works in IE9... somehow. So I suspect in practice this pattern is not used on the web so far. The question is what we should define it to do for the inevitable situation when some clever soul decides to use it. Conceptually, using the global of the realm of the function involved (i.e. the Chrome/Firefox/IE10 behavior) makes sense to me. -Boris
Received on Monday, 23 September 2013 16:40:06 UTC