- From: Mark Miller <erights@gmail.com>
- Date: Sun, 22 Feb 2015 14:02:58 -0800
- To: Domenic Denicola <d@domenic.me>
- Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>, "es-discuss@mozilla.org" <es-discuss@mozilla.org>
- Message-ID: <CAK5yZYiJmNvS_5o18r77xO=fs8gwzfodyT1RncBd=hDaOpRw_Q@mail.gmail.com>
https://heycam.github.io/webidl/#ImplicitThis says: If the [ImplicitThis] <https://heycam.github.io/webidl/#ImplicitThis> extended > attribute <https://heycam.github.io/webidl/#dfn-extended-attribute> appears > on an interface <https://heycam.github.io/webidl/#dfn-interface>, it > indicates that when a Function corresponding to one of the interface’s > operations <https://heycam.github.io/webidl/#dfn-operation> is invoked > with thenull or undefined value as the this value, that the ECMAScript > global object will be used as the this value instead. This is regardless > of whether the calling code is in strict mode. "the ECMAScript global object"? Which one? (Even if it is clear from context, please assume I do not have that context.) On Sun, Feb 22, 2015 at 1:55 PM, Domenic Denicola <d@domenic.me> wrote: > 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 > -- Text by me above is hereby placed in the public domain Cheers, --MarkM
Received on Sunday, 22 February 2015 22:03:26 UTC