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

> From: Boris Zbarsky [mailto:bzbarsky@MIT.EDU]
> 
> On 8/15/12 3:32 PM, Travis Leithead wrote:
> > I was curious just how "bad" the currently reported bug actually is. I ran a
> query looking for use of var indexedDb and var requestAnimationFrame
> across our web data index (which is unfortunately about a year old). jQuery
> uses the requestAnimationFrame a lot--but their use is contained to the
> jQuery scope closure. Modernizer was also using the var indexedDb
> technique, but Modernizer also runs in a scope closure and thus is not
> affected by this issue. In fact, any major library (and a lot of other sites that
> have adopted the "module pattern") won't be affected by this at all.
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=770844#c29 claims there is
> actual site breakage involved.  Presumably Jonas can give you more detailed
> info here; ccing him.

Would love to hear more on this front. While I recognize that there is a future potential problem with yet-to-be-speced APIs introducing problems by being read-only, it seems like that problem can be solved by default-replaceable behavior. As to future name collisions with existing global scope vars, well, we as spec authors and implementers have some degree of control over that.

I still have my doubts about the magnitude of this problem, but if I'm wrong then I'd at least like to be able to grandfather-in some legacy APIs like addEventListener (or other APIs that make sense to have a single shared entry point for easy monkey patching). I suspect that most APIs won't fall into this category as they are meant to be singleton instances on the global (and nowhere else), e.g., the Web Performance APIs requestAnimationFrame, performance, etc.


> > Personally, I'd like to avoid making a change to IE in this regard if I can avoid
> it.
> 
> Are you planning to drop the prefixed name in IE?

Eventually, yes. But I was referring to the way we build our type system which is a much more wide-spread and potentially disruptive change.

Received on Thursday, 16 August 2012 17:24:43 UTC