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

> From: Boris Zbarsky [mailto:bzbarsky@MIT.EDU]
> 
> On 10/5/12 7:35 PM, Cameron McCormack wrote:
> > * What was the conclusion on whether properties for IDL operations
> > also need to move down to be own properties?
> 
> I don't know that we reached one.  I think Brendan wanted to move them
> down.  I don't think I have a strong opinion.  Not sure what Travis
> thinks.  Opera already has them down there, I think.  The Chrome/Safari
> folks are being quiet as usual...

Pulling from earlier in the thread:

> 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.

I think the concern is that both operations and attributes have the potential
problem. So, we probably need to extend the mitigation to operations as well.
However, I'd like to only apply this to operations on Window (and those
That mix-in to it, as requestAnimationFrame does:
http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/RequestAnimationFrame/Overview.html#the-WindowAnimationTiming-interface), which would allow EventTarget to not get flattened down.

I suspect that most new stuff will want to be added to the Window (as opposed 
to the EventTarget interface), and so will fall under the protection of this
workaround.

Received on Saturday, 6 October 2012 04:07:25 UTC