W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2015

Re: Global method calls

From: Mark Miller <erights@gmail.com>
Date: Sun, 22 Feb 2015 14:02:58 -0800
Message-ID: <CAK5yZYiJmNvS_5o18r77xO=fs8gwzfodyT1RncBd=hDaOpRw_Q@mail.gmail.com>
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>
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

This archive was generated by hypermail 2.3.1 : Sunday, 22 February 2015 22:03:27 UTC