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

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

From: Domenic Denicola <d@domenic.me>
Date: Thu, 26 Feb 2015 23:30:12 +0000
To: Boris Zbarsky <bzbarsky@mit.edu>, "public-script-coord@w3.org" <public-script-coord@w3.org>
Message-ID: <CY1PR0501MB1369C0FFF3A1D414A15D8783DF140@CY1PR0501MB1369.namprd05.prod.outlook.com>
This sounds reasonable to me, for what it's worth. (Including your follow-up mail.)

Kentaro, CC'ed, may know more about whether Blink is willing/able to change the implementation.

-----Original Message-----
From: Boris Zbarsky [mailto:bzbarsky@mit.edu] 
Sent: Thursday, February 26, 2015 09:25
To: public-script-coord@w3.org
Subject: Interaction of named properties and own properties in the [OverrideBuiltins] case seems weird

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

  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
2) In [[DefineOwnProperty]], the named setter/creator is called even if
    there is an own property of that name, if the object is
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.


Received on Thursday, 26 February 2015 23:30:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC