为什么在Internet Explorer中window.self的窗口不一样? [英] Why is window not identical to window.self in Internet Explorer?

查看:127
本文介绍了为什么在Internet Explorer中window.self的窗口不一样?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

有一个令人讨厌的背景,涉及到我是如何发现的,但为什么 self 属性不完全等于窗口本身?



在Safari和Firefox和朋友中,结果如我所料:

 > window == window.self 
true
>窗口=== window.self
true

在Internet Explorer中也是如此,但是:

 >> window == window.self 
true
>>窗口=== window.self
false

有人可以解释不一致吗?究竟什么是窗口对象指向的 self 属性?

解决方案

这不是全部,窗口! == window.window



我相信我们可能看到的是内窗和外窗之间的区别'对象。当然其他浏览器都有这些(例如: Moz );它们通常用于从自己的代码内外显示窗口的不同视图。



内部窗口包含您的全局变量和文档特定的成员。外部窗口可以通过窗口引用(例如 frames [n] parent 开启者,显然 self 。它绑定到所有者视口(浏览器窗口/框架),所以例如。当您将iframe导航到新文档时,父文档在其iframe中仍然会看到相同的身份窗口对象。



在一个明智的浏览器对象模型设计中,将有单独的对象,但是当Netscape最初被Netscape抛在脑后时,对于优雅来说很少考虑,导致这个和许多其他界面有太多的重载( form ,一个元素叫做 submit ,任何人?)。



出现,使其成为脚本的单个对象,即使它不在下面。在IE中,有时掩码会滑倒:看起来像窗口可以让你看到内部的窗口,而且没有黑客可以让它 === 对外窗口。



ETA:实际上来想想,甚至有一些(差)的理由。未写入多个全局上下文的ECMAScript规范定义了窗口,并且的未绑定版本 ,作为检索全局变量范围对象,这将是内部窗口。



作为DOM / BOM的一部分的其他属性不在ECMA规范,所以他们可以返回不同的东西(必须为了跨框架脚本)。


There's a convoluted backstory involving how I came across this, but why is the self property not exactly equal to the window itself?

In Safari and Firefox and friends, the results are as I'd expect:

> window == window.self
  true
> window === window.self
  true

The same isn't true in Internet Explorer, though:

>> window == window.self
   true
>> window === window.self
   false

Can anybody account for the inconsistency? To exactly what is the self property of the window object pointing? It casts to something with equality, which is even more vexing.

解决方案

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

这篇关于为什么在Internet Explorer中window.self的窗口不一样?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆