- From: <bugzilla@jessica.w3.org>
- Date: Sun, 03 Jul 2011 21:45:49 +0000
- To: public-script-coord@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