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

[Bug 8241] Named properties on window

From: <bugzilla@jessica.w3.org>
Date: Sun, 03 Jul 2011 21:45:49 +0000
To: public-script-coord@w3.org
Message-Id: <E1QdUU9-0005hr-5F@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8241

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjs@apple.com,
                   |                            |simonp@opera.com,
                   |                            |w3c@adambarth.com

--- Comment #17 from Cameron McCormack <cam@mcc.id.au> 2011-07-03 21:45:47 UTC ---
(Adding some Opera/Chrome/WebKit people.)

(In reply to comment #16)
> 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.

OK.

> 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

Ah, thanks for pointing this out.  That makes more sense.

> > 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

So that is definitely simpler and doesn't need the hook I added to Web IDL.  It
means the interface can remain a non-[OverrideBuiltins] one.  (It also means no
further spec change would be needed, except perhaps to remove the Web IDL hook
which otherwise wouldn't be used.  Note that the HTML spec doesn't yet use the
hook; that's bug 13093.)

Does anyone have an opinion on this simpler behaviour?

-- 
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, 3 July 2011 21:45:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:04 UTC