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

Boris Zbarsky wrote:
> On 8/15/12 5:08 PM, Brendan Eich wrote:
>> Usually window.[standardized property name] is last -- this matters 
>> below.
>
> 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).

Ah, thanks.

>   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 
you suggest).

/be

Received on Thursday, 16 August 2012 21:31:07 UTC