Re: [[Call]] behaviour of operations

On 22/08/11 05:44, Cameron McCormack wrote:
> [Sorry for the duplicate Mark, forgot to copy the list.]
>
> Hi Mark.
>
> On 22/08/11 12:49 PM, Mark S. Miller wrote:
>  > This approach risks destroying all the progress ES5.1/strict made over
>  > ES3 in preventing global object leakage. The window is a singleton. Any
>  > method of window that actually needs access to its window when invoked
>  > as a function should just lexically capture it. If "alert('foo')" is
>  > supposed to do the same thing as "window.alert('foo')",
>  > "window.alert.call(window, 'foo')" and "window.alert.call(undefined,
>  > 'foo')", then it should do the same thing as
>  > "window.alert.call(otherWindow, 'foo')". If alert does not depend on its
>  > this-binding at all, then all these will simply be equivalent.
>
> I tested just now which window `window.func.call(otherWindow)` uses:
>
> http://people.mozilla.org/~cmccormack/tests/window-this-binding.html
>
> This uses window.postMessage as the function to test. In
> Firefox/Safari/Chrome/Opera doing `window.postMessage.call(otherWindow,
> "test, "*")` sends a message to otherWindow.
>
> I also just tested bare alert(...) and `window.alert.call(null, ...)` in
> strict mode in Firefox/Safari/Chrome, and they all successfully show the
> alert in both cases.

The important case here therefore is cases of alert.call({}, "foobar") — 
i.e., the case of an function which doesn't depend on this being called 
with thisArg being something that is not undefined, null, or a Window 
object — where it almost certainly doesn't matter what we specify.

The basic options are to ignore this entirely, or to be consistent on 
the Window object and require everything to have Window/undefined/null 
as the this argument.

I believe the only operations which this affects is alert, confirm, 
prompt, print, and showModalDialog. We probably want any future 
additions to the Window object to behave similarly to what the current 
ones do.

That said, I'm not too fussed about which option is chosen here.

Also: we have the same issue with this-coercion with attribute 
getters/setters, because otherwise "window" will throw (as the getter on 
the Window object isn't called with a Window as this). Whatever is 
decided should be used for both.

-- 
Geoffrey Sneddon — Opera Software
<http://gsnedders.com>
<http://opera.com>

Received on Monday, 29 August 2011 11:41:06 UTC