Re: [WebIDL] Which realm should be used for coercing null/undefined this values to "the" global object?

Le 23/09/2013 18:39, Boris Zbarsky a écrit :
> 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.
Maybe IE9 has a form of self-hosted addEventListener, somthing like:
     EventTarget.prototype.addEventListener = function(type, listener){
         // use |this| as an object
     }

IE9 has no support for strict mode, so the code would be non-strict and 
"this" has the global object as value by default when the function is 
called as a function (as opposed to as a method). That could explain why 
"addEventListener()" works, but "addEventListener.call(undefined)" doesn't.

This sort of reverse-engineering is fun :-) But if someone from 
Microsoft wants to jump in to spoil the answer, that'd be great too!

> 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.
The sane behavior would be for 
"something.addEventListener.call(undefined, ..." to throw a TypeError 
(on the basis that undefined is not a platform object). But I imagine IE 
moved away from that behavior for web compat?

> Conceptually, using the global of the realm of the function involved 
> (i.e. the Chrome/Firefox/IE10 behavior) makes sense to me.
Assuming throwing a TypeError isn't an option, if by "the function" 
you're referring to addEventListener, I agree with you. In that 
instance, the addEventListener is the frame's one, so the currentTarget 
should be the frame, agreed.

David

Received on Monday, 23 September 2013 21:44:24 UTC