[Bug 8241] Named properties on window

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8241

Cameron McCormack <cam@mcc.id.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |adrianba@microsoft.com,
                   |                            |travil@microsoft.com
         Resolution|FIXED                       |

--- Comment #9 from Cameron McCormack <cam@mcc.id.au> 2011-06-19 22:41:54 UTC ---
I assumed since there was no [OverrideBuiltins] on the interface that that's
how it behaved everywhere.  Stupid of me to assume. :)

Here's a small test (not to do with var, just with visibility of the named
properties):

http://people.mozilla.org/~cmccormack/tests/window-named-override.html

* Firefox shows window objects for toString, open, alert & history, and
  do the normal property lookup for document and the variable.  (This might be
  because `window.hasOwnProperty("document") == true` in Firefox.)

* Safari/Chrome show window objects for toString, open & alert, and do
  normal property lookup for document, history and the variable.  (This might
  be because IDL attributes are still own properties on the object in these
  implementations.)

* Opera shows a window object for toString, document & history, and does
  normal property lookup for open, alert and the variable.  (So maybe Opera
  is not letting named properties override functions from Window, but
  otherwise is [OverrideBuiltins].)

* IE does normal property lookup for all of them.

I guess Firefox/Safari/Chrome behaviour can be summarised as "resolve own
properties first, then named properties, then properties from the prototype".

IE's behaviour matches the spec for a non-[OverrideBuiltins] interface -- any
properties that exist on the object itself or prototype get resolved in
preference to the named properties.  This is also the most consistent of the
lot.  Would pages with non-IE code paths break if all the other browsers
switched to this?

All of this might be more a question for the already-resolved bug 10340, but it
does impact on how we might require [ReplaceableNamedProperties] to be
implemented.


We already require funny [DefineOwnProperty] etc. behaviour to handle named
properties, so I don't think it's too much of a stretch to extend them to
handle [ReplaceableNamedProperties].  The alternative which I guess is what
Boris is alluding to is to have named properties appear to be on an object
somewhere in the prototype chain instead, so that assigning to them or doing a
variable declaration gets the right behaviour without adding more specialness
into [DefineOwnProperty].

If we work under the assumption that Window is indeed non-[OverrideBuiltins],
like IE, then that extra object in the prototype chain still needs to have
special [GetOwnProperty] behaviour so that it first resolves properties from
its own properties or its prototype chain before returning the named
properties.

If we did something Safari/Chrome-like, where you resolve own properties, then
named properties, then prototype properties, then you could stick an extra
object in the prototype chain above the Window object which behaved like
[OverrideBuiltins].  Again, this would avoid making the changes to
[[DefineOwnProperty]] I made in comment 7.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Sunday, 19 June 2011 22:41:56 UTC