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-boun...@mozilla.org] On Behalf Of Domenic Denicola Sent: Sunday, February 22, 2015 16:39 To: Mark Miller Cc: public-script-co...@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:erig...@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 _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
