- From: <bugzilla@jessica.w3.org>
- Date: Mon, 20 Jun 2011 05:18:53 +0000
- To: public-script-coord@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8241 Brendan Eich <brendan@mozilla.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |brendan@mozilla.org --- Comment #12 from Brendan Eich <brendan@mozilla.org> 2011-06-20 05:18:52 UTC --- (In reply to comment #11) > In the Firefox, case at least, I think part of your problem is that you're > lumping together _different_ sorts of named properties. In particular frame > names are treated quite differently from properties that come from the global > scope polluter in Gecko; I can't speak to other browsers. > > The exact Gecko name resolution process on Window is: > > 1) Something with standard classes (Object, Array, etc). Not quite sure what > and how those interact with named frames and the like. > 2) Look for a named frame with that name. This is a decision tree (skinny, one path only, so a list). Since (2) comes after (1) we can be sure that buitl-ins (standard classes such as Object) are resolved in preference to frames of the same name. Of course frame indexes cannot name any built-in in ECMA-262, so those are resolved in a step (0). Also, there is a step (1.5) where 'constructor' is handled specially, so that a frame with that name cannot shadow the prototype property of that name on Window. I'm not sure this is anything but a historical accident, though. Re: comment 10: it is important for integrity and optimizability that var-defined bindings be non-configurable. /be -- 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 05:18:59 UTC