RE: "var" declarations shadowing properties from Window.prototype

> From: Brendan Eich [mailto:brendan@mozilla.com]
> 
> Cameron McCormack wrote:
> > Brendan Eich:
> >> As bz and others point out, the object detection w/ var pattern can
> >> arise for operations, e.g. for requestAnimationFrame, using the same
> >>
> >>    var requestAnimationFrame = window.mozRequestAnimationFrame ||
> ...
> >> || window.requestAnimationFrame;
> >>
> >> pattern. So WebIDL operations (JS methods) on the global would be
> >> promoted to "own" too. They'd be configurable, if I recall correctly,
> >> and either writable or replaceable. Do I have that right?
> >
> > OK.  So one thing that I think has been pointed out is that moving
> > properties for operations on to window makes it harder to monkeypatch
> > addEventListener and friends.

Indeed, and this is a scenario that we [IE] care deeply about given that we have tools that use this behavior extensively.


> >   We *could*, if we thought it was important, have the properties on
> > window forward on to the ones from the prototype.
> 
> Less magic if we can avoid it.

+1


> > 3. The only writable IDL attributes on Window are:
> >
> >      attribute DOMString name;
> >      attribute DOMString status;
> >      attribute WindowProxy? opener;
> >
> > and all of the event handler attributes like "onclick".  How do these
> > need to behave if script blithely tries to use variables of the same
> > name?  With this:
> >
> > <script>
> >     alert([window.status, typeof window.status]);
> >     window.status = "hello";
> >     alert([window.status, typeof window.status]); </script> <script>
> >     var status;
> >     alert([window.status, typeof window.status]);
> >     status = 1;
> >     alert([window.status, typeof window.status]); </script>
> >
> > Gecko and Opera alert:
> >
> >   ,string
> >   hello,string
> >   ,undefined
> >   1,number
> 
> Yes, this is more lossage compared to historical norms that WebKit-based
> browsers still uphold.
> 
> The lack of a var initialiser means that the (historically own) status accessor
> must have its getter or setter invoked. 'var' doesn't replace an existing own
> property in any scenario, historical or ES5+erratum-fix.
> 
> > while Chrome and Safari alert:
> >
> >   ,string
> >   hello,string
> >   hello,string
> >   1,string
> >
> > which seems to indicate that they're setting the IDL attribute.
> 
> Did you try IE8, 9 and 10? I suspect they match but can't test.

IE9/10 match Gecko/Opera in the above example.


> > With this:
> >
> > <body onerror="alert('exception')">
> > <script>
> >     alert([String(window.onclick), typeof window.onclick)]); </script>
> > <script>
> >     var onclick = 1;
> >     alert([String(window.onclick), typeof window.onclick]); </script>
> >
> > Gecko, Opera and Chrome alert:
> >
> >   null,object
> >   1,number
> >
> > which could mean shadowing or treating "onclick" as IDL type "any" and
> > treating non-Function values as null, while Safari alerts:
> >
> >   null,object
> >   null,object
> >
> > which looks like it's invoking the setter but ignoring the assignment
> > of a non-Function value.
> 
> Seems a Safari deviation.

IE9/10 also mimic Gecko/Opera/Chrome above. +1 on Safari deviation.

Received on Wednesday, 15 August 2012 18:25:51 UTC