[Bug 8241] Named properties on window


--- Comment #10 from Cameron McCormack <cam@mcc.id.au> 2011-06-20 00:56:52 UTC ---
I was fooled earlier by the Web Console in Firefox -- it doesn't actually have
document as an own property on window.  (That's just in the Web Console's
global object. :/)  So why document is given special treatment is not apparent
to me.

Here are some tests wrt var versus assignment.


These test show using var to declare, or just assigning to, variables names
toString, open, alert, document, history and variableName, either before or
after those names become named properties (i.e. before or after <iframe>s with
those names are in the document).  They show the values and whether the
properties are configurable/enumerable/writable (except for Opera, where we
don't have Object.getOwnPropertyDescriptor yet).

So according to ES5, using var to declare a variable P at the top level should
do this:

  * If [[HasProperty]](P) returns false:
      * Call [[DefineOwnProperty]]
          (P, {value:undefined, writable:true,
               enumerable:true, configurable:false}, true).
      * Call [[Put]](P, undefined, isStrictMode).

Variable assignment is this, in non-strict mode:

  * Call [[Put]](P, value, false).

Since Window is an object with named properties, according to Web IDL at the
moment we silently treat all non-configurable property definitions and
configurable.  (That's a recent change, so nobody does that yet.  That might
also change a bit if proxies gain the ability to expose non-configurable
properties.)  So per spec there should be no difference between var declaration
and plain assignment with window as the global object.

All of the variable names we're testing with the exception of variableName
should already exist as properties from the Window object's prototype chain
(but not be own properties).

So for window-named-var-before and window-named-assign-before, what we would
expect from the specs as they stand is to have configurable/writable/enumerable
own properties on the Window object before the iframes are added, with their
values as specified.  After the iframes are added, looking up properties on
window should be no different.

This is how implementations currently differ from this:
  * Everyone creates non-configurable properties for the var declarations.
  * WebKit makes the var declared properties appear to be non-writable and
    non-enumerable.  (Seems bogus.)
  * Firefox ignores the document variable declaration and assignment.
  * Safari/Chrome don't allow document to be declared as a variable, they
    throw an exception.  history can be, though.
  * Safari appears to override [[Get]] to return the named values, rather than
    [[GetOwnProperty]] -- so you can see that `window.toString == 1` but 
    `Object.getOwnPropertyDescriptor(window, "toString").value == aWindowObj`.
  * (Chrome and Safari both have some weirdness where the value of
    window.document is the same both before and after the
    <iframe name=document> is added, but afterwards the object cannot be
  * IE doesn't let document or history variables be declared at all, it throws
    an exception.  So document and history named properties show through.
  * In window-named-assign-before, Firefox ignores the attempt to assign
    to history without a variable declaration, thus the named property shows
    through after the <iframe name=history> is added.

window-named-var-after and window-named-assign-after should per current specs
also behave the same as each other.  Each of the properties should already
exist on window: [[HasProperty]] will return true, so variable declarations are
the same as plain assignment.

  * In Firefox/Safari/Chrome, any difference between running -var-after and
    -assign-after is just in the configurability of some properties (if any).
  * Firefox still exposes document as an HTMLDocument object, so assigning to
    it has failed again.  The other properties are exposed with their new
  * Chrome behaves the same as Firefox.
  * WebKit exposes DOMWindow objects for all properties except document and
    history, just as with the -var-before/-assign-before tests.
  * IE exposes the new property values for toString, open, alert and
    variableName and the document/history objects for document and history
    in -var-after.  -assign-after is the same except that toString is exposed
    as the toString function!  Not sure why assigning to toString without a
    variable declaration should fail.

I didn't test yet what would happen if Object.defineProperty were used for each
of these property names on window.

So what is the upshot of all of this?  I'm guessing that it's important for
compatibility for document to be exposed as the HTMLDocument object always. 
Apart from that, there's a fair degree of variability.

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 Monday, 20 June 2011 00:56:59 UTC