In ES3, Function.prototype.call would treat a first argument value of undefined or null as the global object instead, which would make the call you wrote work.  ES5 removed this:

  http://people.mozilla.org/~jorendorff/es5.html#sec-15.3.4.4

[LenientThis] is for if you need to work around that.  But I'd like to know if it's really needed before adding it to addEventListener.  Or if we could even remove [LenientThis] from the spec.  It used to be used somewhere in HTML but I can't see it in use now.

We chatted about this:

http://logbot.glob.com.au/?c=mozilla%23developers&s=14%20Aug%202012&e=14%20Aug%202012#c326654

Anyone thought about this some more? Are the problems raised with HTML fixed?

This isn't about [LenientThis]; [LenientThis] doesn't do what's needed here.

Gecko's WebIDL bindings effectively implement the ES3 behavior, for what it's worth: they always compute "this" to an object, just like non-strict-mode functions do in ES5...

Is there a black-box-detectable difference between putting [ImplicitThis] on all interfaces implemented by the global object (which may not be a Window) and simply having [ImplicitThis] on all interfaces?

(In reply to comment #5)
> Is there a black-box-detectable difference between putting [ImplicitThis] on
> all interfaces implemented by the global object (which may not be a Window)
> and simply having [ImplicitThis] on all interfaces?

No, there would be no difference, because when calling a function from some [ImplicitThis]-annotated not-implemented-by-Window interface, you will get a TypeError thrown from step 1 of http://dev.w3.org/2006/webapi/WebIDL/#es-operations, and if it wasn't [ImplicitThis]-annotated then you would get a TypeError because http://es5.github.com/#x10.4.3 would turn the null into the global object, and this wouldn't be the right kind of object to call the function on.

One of the problems mentioned in the IRC log was that without [ImplicitThis],

  interface WindowProxy {
    readonly attribute WindowProxy window;
  };

you can't actually evaluate `window` in strict mode.  And anyway [ImplicitThis] is currently only defined to work on operations, not attributes.

So we obviously need it for that attribute.  And comment 0 says we need it for window.addEventListener.call().  Do we need it for a specific set of functions, or just for everything on window?  I'm wondering if doing it for everything on window defeats (some of) the purpose of strict mode.

>  interface WindowProxy {
>    readonly attribute WindowProxy window;
>  };

That seems nonsensical.  Shouldn't that attribute be on Window?  There is no actual WindowProxy interface....  (Or no actual Window interface; pick your poison.)

But yes, the getter for that attribute needs to have something like [ImplicitThis].

My gut reaction is that every single thing on Window should have it so we don't break the web, but it's worth checking with the ES folks for what they want here.

(In reply to comment #7)
> >  interface WindowProxy {
> >    readonly attribute WindowProxy window;
> >  };
> 
> That seems nonsensical.  Shouldn't that attribute be on Window?  There is no
> actual WindowProxy interface....  (Or no actual Window interface; pick your
> poison.)

Er, yep.

> But yes, the getter for that attribute needs to have something like
> [ImplicitThis].
> 
> My gut reaction is that every single thing on Window should have it so we
> don't break the web, but it's worth checking with the ES folks for what they
> want here.

Allen, can you tell us about the intentions of strict mode's "not converting null/undefined to the global object" and whether that was intended to apply to everything on the window object, or more for user defined functions?

Per the thread starting at https://lists.w3.org/Archives/Public/public-script-coord/2015JanMar/0109.html, and concluding around https://lists.w3.org/Archives/Public/public-script-coord/2015JanMar/0122.html, we decided on an alternate plan, which I've now updated the title of the bug to reflect:

- All IDL-defined methods should have the [ImplicitThis]-like behavior, where if `this` is undefined, it becomes the global of the realm of the function involved. (Or, the corresponding WindowProxy? ugh).

- This will cause brand check failures immediately when doing things like `Node.prototype.insertBefore.call(undefined, ...)` since a Window is not a Node. So this is good; a TypeError will be thrown as expected.

- Once this is done we can remove [ImplicitThis] from everywhere.

See also https://github.com/whatwg/html/issues/643.

> (Or, the corresponding WindowProxy? ugh).

I would vastly prefer it becoming the actual global.  That's what happens for bareword getters, after all, and it would be good to be consistent.

https://github.com/heycam/webidl/pull/155