That's not all, window!==window.window
!
I believe what we're probably seeing here is the difference between the ‘inner window’ and ‘outer window’ objects. Certainly other browsers have these (eg. Moz); they're typically used to present a different view of the window
from inside and outside its own code.
The inner window holds your global variables and document-specific members. The outer window is accessible to [cross-frame-] scripting via window-references like frames[n]
, parent
, opener
, and apparently self
. It is bound to the owner viewport (browser window/frame), so eg. when you navigate an iframe to a new document, the parent document still sees the same-identity window
object in its iframe.
In a sensible Browser Object Model design there would be separate objects for this, but when JavaScript was originally thrown together by Netscape there was very little consideration for elegance, resulting in this and many other interfaces where there is too much overload (form
with an element called submit
, anyone?).
So for compatibility, the split window has to continue to appear to be a single object to scripts even though it isn't underneath. In IE, sometimes the mask slips: it seems like saying window
gets you the inner window, and there's no hack to make it ===
against the outer window.
ETA: Actually come to think of it, there's even some (poor) justification for this. The ECMAScript spec, which is not written with multiple global contexts in mind, defines window
, and the unbound version of this
, as retrieving the global variable scope object, which would be the inner window.
The other properties, being part of the DOM/BOM, are not within the scope of the ECMA spec, so they can return something different (and must, for the sake of cross-frame scripting).
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…