18547 2012-08-13 12:13:49 +0000 Make all IDL methods/attributes have [ImplicitThis] behavior, and then get rid of [ImplicitThis] 2016-09-08 20:54:40 +0000 1 1 1 Unclassified WebAppsWG WebIDL unspecified All Windows 3.1 RESOLVED FIXED [v1] P2 normal --- 1 Ms2ger cam allen annevk bzbarsky cam d mike public-script-coord www-dom public-webapps-bugzilla oldest_to_newest 72118 0 Ms2ger 2012-08-13 12:13:49 +0000 window.addEventListener.call(null, "a", function (e) { w(e) }) seems to work, while it isn't allowed per WebIDL. I'm not actually sure what [ImplicitThis] is good for, and why we don't always turn null/undefined into the window; maybe Cameron can explain. 72155 1 cam 2012-08-14 07:59:20 +0000 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. 72156 2 Ms2ger 2012-08-14 08:37:39 +0000 We chatted about this: http://logbot.glob.com.au/?c=mozilla%23developers&s=14%20Aug%202012&e=14%20Aug%202012#c326654 74188 3 annevk 2012-09-21 10:07:42 +0000 Anyone thought about this some more? Are the problems raised with HTML fixed? 78838 4 bzbarsky 2012-11-26 16:26:15 +0000 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... 79286 5 bzbarsky 2012-12-03 14:08:50 +0000 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? 79593 6 cam 2012-12-07 00:59:04 +0000 (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. 79596 7 bzbarsky 2012-12-07 01:23:17 +0000 > 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. 79597 8 cam 2012-12-07 01:30:03 +0000 (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? 124913 9 d 2016-02-08 19:33:23 +0000 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. 124914 10 bzbarsky 2016-02-08 19:36:52 +0000 > (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. 127346 11 d 2016-09-08 20:54:40 +0000 https://github.com/heycam/webidl/pull/155