W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

[Bug 8241] Named properties on window

From: <bugzilla@jessica.w3.org>
Date: Fri, 01 Jul 2011 17:48:39 +0000
To: public-webapps@w3.org
Message-Id: <E1QchpX-0003fT-Jm@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8241

Tony Ross [MSFT] <tross@microsoft.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |tross@microsoft.com
         Resolution|FIXED                       |

--- Comment #16 from Tony Ross [MSFT] <tross@microsoft.com> 2011-07-01 17:48:37 UTC ---
> IE is the odd one out, where frame properties don't
> override anything except for GSP properties.  Did IE do this to match what the
> specs currently say?  I'm a little surprised that didn't break anything.

Sorry for the delay in my response. I've been digging through our bug database
to see if we had noticed any impact from this change. I didn't find anything.

>   IE:
>     * Frame properties override nothing.
>     * GSP properties override:
>         Window.prototype builtin properties
>       but not:
>         Window.prototype added properties
>         or anything else.

This is slightly incorrect. GSP properties do not override Window.prototype
builtin properties in IE. I suspect you arrived at this conclusion because your
test case attempts to override the "stop" builtin, but "stop" is not defined in
IE. IE's actual behavior is:

  IE:
    * Frame properties override nothing (except GSP)
    * GSP properties override nothing

> Here is a simple first order approximation to the different resolution orders
> (and this is most of a difference for IE):
> 
>   1. Own properties on window (which would include JS builtin
>      global properties like Array, Object, etc.)
>   2. Frames
>   3. Properties from the prototype chain (which would include
>      "constructor" & event listener properties)
>   4. Global scope polluter
> 
> Would this work?

This is close to the behavior IE has today, except for resolving frames before
the prototype chain. We have not seen resolving frames after the prototype
chain break anything. Thus I prefer to avoid special-casing frames in this way
and instead stick with IE's current behavior:

   1. Own properties on window (which would include JS builtin
      global properties like Array, Object, etc.)
   2. Properties from the prototype chain (which would include
      "constructor" & event listener properties)
   3. Frames
   4. Global scope polluter

-- 
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 Friday, 1 July 2011 17:48:40 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:46 GMT