W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2015

Interaction of named properties and own properties in the [OverrideBuiltins] case seems weird

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Thu, 26 Feb 2015 09:24:49 -0500
Message-ID: <54EF2CB1.3060706@mit.edu>
To: "public-script-coord@w3.org" <public-script-coord@w3.org>
Right now, per the Web IDL spec, [OverrideBuiltins] causes named 
properties to shadow previously set own properties, due to the ordering 
of these steps in 
<http://heycam.github.io/webidl/#dfn-named-property-visibility>:

  4. If O implements an interface that has the [OverrideBuiltins]
     extended attribute, then return true.
  5. If O has an own property named P, then return false.

I would like to propose changing this behavior.  Specifically, I would 
like to propose that whether an interface is [OverrideBuiltins] or not 
should not affect the interaction of named properties and own properties 
on [[Get]].

Looking at the spec as of today, [OverrideBuiltins] affects the 
interaction with own properties in the following ways:

1) In [[GetOwnProperty]] named props are returned before own props if
    [OverrideBuiltins].
2) In [[DefineOwnProperty]], the named setter/creator is called even if
    there is an own property of that name, if the object is
    [OverrideBuiltins].
3) In [[Delete]], the named deleter is called even if there is an own
    property of the same name, if the object is [OverrideBuiltins] and
    has a corresponding named property.

Now in practice, the only things in the platform with named deleters 
also have named creators, so they will never have own properties.  So 
item 3 is pretty much irrelevant.  For item 2 I don't have a strong 
feeling for how it should work, esp. once we define a [[Set]] that 
always invokes named setters.  But I do somewhat care about item 1: I 
think that if you set document.foo then later adding an <img name="foo"> 
should not cause your previously-set value to disappear.

As always, we need some testcases.  Of particular interest to me is 
http://jsfiddle.net/3gfe9s57/3/ on which I observe the following 
behavior in various UAs:

Firefox: Preexisting own property is not shadowed by named property.
Chrome: Seems to actually define/delete own properties as you
         add/remove <img> elements; clobbers existing own property.
Safari: Does pretty much what the spec says right now for this
         testcase: the named property shadows the own property.
IE: Same as Firefox.

Basically, I'm proposing to standardize the Firefox/IE behavior here, as 
being less weird and magical.

-Boris
Received on Thursday, 26 February 2015 14:25:20 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 26 February 2015 14:25:21 UTC