RE: Global method calls

OK, I think I might be on the trail of this one.

[1] indicates a plan to make [Global]-annotated objects, like the Window object, apply "[ImplicitThis] behavior" to the object's methods and the methods of anything that shows up in its prototype chain. [ImplicitThis] behavior is defined at [2], and does exactly what we need, i.e. makes calls with undefined `this` get translated into calls with the window.

However, the plan at [1] seems to be only half-executed, in that Window defined at [3] does not have [ImplicitThis], but the definition of [PrimaryGlobal] and [Global] at [4] does not imply [ImplicitThis] behavior. Due to this half-way state, [ImplicitThis] seems to be "dead code," as evidenced by [5].

If I am indeed reading the situation correctly, I think the spec-level fix is to either implement the plan in [1], or to put [ImplicitThis] (back?) on the globals *and* on EventTarget. I actually prefer the latter, since the way in which tagging [Window] as a [Global] implicitly makes EventTarget, defined in another spec, take on [ImplicitThis] behavior, seems hard to follow.

[1]: https://lists.w3.org/Archives/Public/public-script-coord/2013JulSep/0657.html
[2]: https://heycam.github.io/webidl/#ImplicitThis
[3]: https://html.spec.whatwg.org/multipage/browsers.html#window
[4]: https://heycam.github.io/webidl/#Global
[5]: https://www.google.com/search?q=ImplicitThis+site%3Awhatwg.org&ie=utf-8&oe=utf-8#q=%2BImplicitThis+site:whatwg.org

-----Original Message-----
From: es-discuss [mailto:es-discuss-bounces@mozilla.org] On Behalf Of Domenic Denicola
Sent: Sunday, February 22, 2015 16:39
To: Mark Miller
Cc: public-script-coord@w3.org; es-discuss@mozilla.org
Subject: RE: Global method calls

Thanks Mark. At this point it may tend toward more of a public-script-coord question...

From: Mark Miller [mailto:erights@gmail.com] 

> If it is strict code, then this is definitely a Call(addEventListener, 
> undefined, <"foo", function () {}>)
> 
> I won't try to speak definitively for what happens if the code above is sloppy. But I believe the answer is the same. If the receiver is sloppy, it is up to it to promote an undefined this-binding to its realm's global object. As a builtin, it is neither strict nor sloppy, and its spec should state what it does with an undefined this-binding.

The added weirdness here is that addEventListener is actually a method of EventTarget, which Window derives from. (And then, of course, the window proxy masks direct access, at least when you do `window.addEventListener`---but apparently the window proxy is not involved in my case.)

The spec for addEventListener [1] doesn't mention what to do with an undefined `this` binding. Although the language is of the typical imprecise-DOM-spec-type, as far as I can tell it assumes that its `this` is always an `EventTarget` instance, which then has "an associated list of event listeners" it operates on.

At this point I must imagine that there is some special handling taking place somewhere else in the web ecosystem, possibly in WebIDL, that will ensure addEventListener (and possibly any other method?) will use the global window (but not the window proxy?) when called with undefined `this`. I don't know where to find that, though: I looked through [2] without much luck, and Ctrl+Fing for [[Call]] throughout WebIDL does not give anything fruitful.

[1]: https://dom.spec.whatwg.org/#dom-eventtarget-addeventlistener
[2]: https://heycam.github.io/webidl/#Global

> It is quite bizarre that you also get undefined when you don't prepend "use strict" to the first script. globalFunc should then be sloppy. A sloppy function should never see its "this" bound to undefined, or indeed to any non-object value. I do not understand what might be going on here.

You are right; please disregard this part. I don't get undefined in the given example---only when adding "use strict" to both.

_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Received on Sunday, 22 February 2015 21:56:26 UTC