Prev: Would you stop for a moment?!
Next: What’s the best way to solve this kind of javascript dead loop?
From: Garrett Smith on 9 Feb 2010 13:35
David Mark wrote:
> On Feb 8, 7:49 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
>> I'm confused about IE's evaluation of window == document.
>>
>> IE:
>> window == document; // true
>> document == window; // false
>>
>> I came across this while testing to see if an object is a window.
>>
>> I need this so that in the registry cleanup for DOM events, that if the
>> object is window, then don't unregister callbacks. This works fine as
>> callbacks for window don't need cleanup, but it is also important as
>> removing unload callbacks before they fire will mean those callbacks
>> won't fire ever -- that's bad.
>
> Will you please put that Kool-aid down? You don't need such cleanup
> if you avoid the circular references we have discussed here ad
> nauseam.
>

No worries, kid: I spare the Kool aid for girls like you. It's either
protein shakes, tea, or coffee.

>> So I want to continue the loop if the object is window, but came across
>> this oddity. I am going to base my programming strategy around the
>> operands being in a certain side of == -- and I really don't like doing
>> that -- then at the very least I need a comment explaining why. I can't
>> explain it because I don't understand it. Somebody please fix that.
>
> No mystery. They are host objects, so they can do whatever they want.
>
Sure thing, they're host objects.

I'm trying to figure out this behavior in a particular case. You don't
seem to have the answer.

> You should change your design so that you do not have to differentiate
> between windows and documents.
Were you making comments about code you haven't read? Or is it about the
strategy mentioned in the (my) first paragraph of the OP?
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Asen Bozhilov on 9 Feb 2010 13:39
Garrett Smith wrote:
> I'm confused about IE's evaluation of window == document.
>
> IE:
> window == document; // true
> document == window; // false

There yet another bug, and you can see same behavior with others host
objects:

window.alert(window == new ActiveXObject('Microsoft.XMLHTTP')); //true
window.alert(new ActiveXObject('Microsoft.XMLHTTP') == window); //
false

window.alert(window == document.documentElement); //true
window.alert(document.documentElement == window); //false
From: Garrett Smith on 9 Feb 2010 18:22
Asen Bozhilov wrote:
> Garrett Smith wrote:
>> I'm confused about IE's evaluation of window == document.
>>
>> IE:
>> window == document; // true
>> document == window; // false
>
> There yet another bug, and you can see same behavior with others host
> objects:
>
> window.alert(window == new ActiveXObject('Microsoft.XMLHTTP')); //true
> window.alert(new ActiveXObject('Microsoft.XMLHTTP') == window); //
> false
>
> window.alert(window == document.documentElement); //true
> window.alert(document.documentElement == window); //false

Interesting.

It seems comparing window with elements in the document is true.

alert(window == document.body)
alert(window == document.links[0])
alert(window == document.body.firstChild)
alert(window == window.item);
alert(window == document.childNodes.item)
alert(window == document.getElementsByTagName("p")[0]);
alert(window == document.body.appendChild(document.createComment("")));
window == document.body.appendChild(document.createElement("div"))

All true, but window is not equal to element that is not in the document
or text node.

alert(window == document.createElement("div"))
alert(window == document.body.appendChild(document.createTextNode("")))

Both false.

We can take == one step further to other objects in IE:
alert( document.childNodes.item == document.body );

The `frames` object is also ==, when it is on the RHS:
alert(window == frames)

Some modern browsers, including IE, report true. Safari 2, Chrome 4,
BB9k all report false. Both browsers provide some sort of proprietary
collection there.

alert(window === frames);
IE, Op10, Chrome 4, Saf 2: false
FF, Saf 3+: true

Reversing the operands as `frames == window` has a different result, but
only in IE.
alert(frames == window);

IE: false

HTML 5 specifies:
"The window, frames, and self DOM attributes must all return the
Window object's browsing context's WindowProxy object."

http://www.w3.org/TR/html5/browsers.html#dom-window

I can sort of see the case for frames === window, if the objects have
identical properties (frames.document == window.document, etc).
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 9 Feb 2010 18:26
Garrett Smith wrote:
> Asen Bozhilov wrote:
>> Garrett Smith wrote:

[...]

> The `frames` object is also ==, when it is on the RHS:
> alert(window == frames)
>
> Some modern browsers, including IE, report true. Safari 2, Chrome 4,
> BB9k all report false. Both browsers provide some sort of proprietary
> collection there.
>
s/Both browsers/Those browsers

--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 9 Feb 2010 18:32
Garrett Smith wrote:
> Asen Bozhilov wrote:
>> Garrett Smith wrote:
>>> I'm confused about IE's evaluation of window == document.
>>>
>>> IE:
>>> window == document; // true
>>> document == window; // false
>>
>> There yet another bug, and you can see same behavior with others host
>> objects:
>>
>> window.alert(window == new ActiveXObject('Microsoft.XMLHTTP')); //true
>> window.alert(new ActiveXObject('Microsoft.XMLHTTP') == window); //
>> false
>>
>> window.alert(window == document.documentElement); //true
>> window.alert(document.documentElement == window); //false
>
> Interesting.

Not particularly. Host objects can do whatever they want.

>
> It seems comparing window with elements in the document is true.
>
> alert(window == document.body)
> alert(window == document.links[0])
> alert(window == document.body.firstChild)
> alert(window == window.item);
> alert(window == document.childNodes.item)
> alert(window == document.getElementsByTagName("p")[0]);
> alert(window == document.body.appendChild(document.createComment("")));
> window == document.body.appendChild(document.createElement("div"))
>
> All true, but window is not equal to element that is not in the document
> or text node.
>
> alert(window == document.createElement("div"))
> alert(window == document.body.appendChild(document.createTextNode("")))
>
> Both false.

All highly uninteresting. Just serves to show that you can't treat host
objects like they are native.

>
> We can take == one step further to other objects in IE:
> alert( document.childNodes.item == document.body );
>
> The `frames` object is also ==, when it is on the RHS:
> alert(window == frames)
>
> Some modern browsers, including IE, report true. Safari 2, Chrome 4,
> BB9k all report false. Both browsers provide some sort of proprietary
> collection there.

They can do whatever they want (and you should avoid relying on the
results).

>
> alert(window === frames);
> IE, Op10, Chrome 4, Saf 2: false
> FF, Saf 3+: true
>
> Reversing the operands as `frames == window` has a different result, but
> only in IE.
> alert(frames == window);
>
> IE: false

Fair enough. :)

>
> HTML 5 specifies:
> "The window, frames, and self DOM attributes must all return the
> Window object's browsing context's WindowProxy object."

And what does that have to do with anything? The tested browsers are
not HTML5 implementations.

>
> http://www.w3.org/TR/html5/browsers.html#dom-window
>
> I can sort of see the case for frames === window, if the objects have
> identical properties (frames.document == window.document, etc).

I can't see it, but they all have a case as they are implementation
dependant host objects. As long as you refrain from treating them like
natives, you'll be fine. ;)
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Would you stop for a moment?!
Next: What’s the best way to solve this kind of javascript dead loop?