"var" declarations shadowing properties from Window.prototype
brendan at mozilla.com
Thu Aug 16 14:30:36 PDT 2012
Boris Zbarsky wrote:
> On 8/15/12 5:08 PM, Brendan Eich wrote:
>> Usually window.[standardized property name] is last -- this matters
> I don't see how it matters at all, actually.
It could matter if there's a stray indexedDB global lurking (set by
script previously) but the var indexedDB = ... code in question wants
the msIndexedDB on IE.
It could matter if a browser is like recent Firefoxes, and it defines
both prefixed and unprefixed, but it also has the ES5.1 erratum fix so
the var indexedDB by itself overrides an inherited
Window.prototype.indexedDB. Then you want the prefixed one first.
>>> Firefox is affected by this problem (e.g., the result of the var
>>> declaration is undefined)
>>> Chrome is not affected by this problem because their var creation
>>> algorithm checks the prototype chain for an existing property name
>> No, Chrome is not affected because their IDL bindings put inherited
>> attributes on the global object as "own" accessors.
> It's not affected for both reasons, at least in the last version of
> Chrome I tested.
Chrome -- really V8 -- doesn't have the ES5.1 erratum fix?
>> That's true, but see above point about order of || terms.
> Again, the order of the || terms doesn't matter. "X || undefined" and
> "undefined || X" both evaluate to X as long as X is not falsy.
Not always -- see above.
>> No. Rather, the erratum at
>> https://bugs.ecmascript.org/show_bug.cgi?id=78 was already fixed by
>> Mozilla, Google, Opera, and I believe IE and Apple.
> It's not fixed by Apple as of the 2012-08-06 WebKit nightly.
> It does seem to be fixed in Chrome dev (22.0.1229.6). It's not fixed
> in Chrome beta (21.0.1180.79).
> We'll see if and when the fix makes it to a final release, but in
> the meantime what's out there in users' hands right now does not have
> the fix.
Rats. This makes Firefox have *two* "kick me" signs taped to its back.
>> Also, WebIDL-reliant spec authors must be careful not to define get-only
>> accessors (readonly attributes) on the global object or interfaces from
>> which it inherits. This leads to the idea that the global object
>> defaults to [Replaceable] (which may be removed from WebIDL as explicit
>> qualifier syntax) and [Unforgeable] must be used selectively for some
>> few historic exceptions.
> Note that there is a middle ground between [Replaceable] and
> [Unforgeable], which is where most props on the global live right
> now.... I suspect for web compat we may want to default all future
> stuff to being [Replaceable] but grandfather in the existing
> non-replaceable things.
Whatever compat gods require. Hard to know whom they'll zap if a change
is tried, or when data collection is "done". This often leads to taking
the safe route and complicating the spec (in this case grandfathering as
More information about the es-discuss