window == document

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.

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.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/

Garrett Smith wrote:

> I'm confused about IE's evaluation of window == document.
>
> IE:
> window == document; // true
> document == window; // false

(I can confirm this for IE 6.0.2800.1106 / JScript 5.6.6626)

Well, those are references to host objects, and JScript is buggy there, too.
It works fine here (always `false') if you use `===' instead of `=='.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

On 09/02/10 01:49, Garrett Smith wrote:
> I'm confused about IE's evaluation of window == document.
>
> IE:
> window == document; // true
> document == window; // false

I may be missing something, but don't you want both of these to evalute
to false? If so, Thomas's suggestion (using ===) should solve the
problem. If you're dealing with some weird edge case, a comment should
do it, IMHO. As if our code wasn't already riddled with "this is only
for IE compatibility" comments ;-)

I've never encountered this case, but I agree: it's definitely weird,
non-standard behavior. I wish there was a way to talk to the IE
developers, to ask them questions like this. With almost every other
browser, you could just look at the source code and see what's going on,
but IE is completely opaque. They don't even have a public bug tracker.


--
stefan

On Feb 9, 10:49*am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> I'm confused about IE's evaluation of window == document.
>
> IE:
> window == document; // true
> document == window; // false

Are you sure that *somewhere* in ECMA-262 it doesn't say that host
objects can change value depending on which side of an equality they
are on? Seems they have a get-out-of-jail-free card for every other
such circumstance.

If that was true, the spec was consistent and the same logic was
applied to identity and strict equality, would that help? ;-)


--
Rob

On Feb 8, 7:49*pm, Garrett Smith <dhtmlkitc...@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.

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

You should change your design so that you do not have to differentiate
between windows and documents.

Stefan Weiss wrote:
> On 09/02/10 01:49, Garrett Smith wrote:
>> I'm confused about IE's evaluation of window == document.
>>
>> IE:
>> window == document; // true
>> document == window; // false
>
> I may be missing something, but don't you want both of these to evalute
> to false? If so, Thomas's suggestion (using ===) should solve the
> problem. If you're dealing with some weird edge case, a comment should
> do it, IMHO. As if our code wasn't already riddled with "this is only
> for IE compatibility" comments ;-)
>
The problem with === is that window === window is not always true.

javascript: alert([window === window.window, window === self])

> I've never encountered this case, but I agree: it's definitely weird,
> non-standard behavior. I wish there was a way to talk to the IE
> developers, to ask them questions like this. With almost every other
> browser, you could just look at the source code and see what's going on,
> but IE is completely opaque. They don't even have a public bug tracker.

They do have a bug tracker (slow, when it works):
http://connect.microsoft.com/IE

I've filed bugs there myself.

Good bugs sometimes get marked as WONTFIX, INVALID, or Can't Reproduce.

The W3C Mailing Lists might seem like a way to talk to IE devs, but they
are a waste of time. The W3C is a pay-to-play organization arrogantly
out of control (put your money where your mouth is or STFU (or we'll ban
you permanently, lie about the reasons and lie and say it's only for two
weeks)).

My current test is based off using window on RHS. Given `a` and `b`, if
they are both the window, then
a == b.window; // true

If either `a` or `b` is `document`, then:
a == b.window; // false

In my code, there isn't any way `a` could be undefined because a
TypeError would prevent the object from being added to the registry:

a.addEventListener // <-- TypeError if a is undefined.

I mention undefined because Where the value on the LHS is undefined or
null and the value on the RHS does not have a window property.

var a;
a === [].window; // true, both are undefined.

But that can't happen in my code as it is now.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/

David Mark wrote:
> On Feb 8, 7:49 pm, Garrett Smith <dhtmlkitc...@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/

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

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/

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/

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.

On Feb 8, 6:49*pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> I'm confused about IE's evaluation of window == document.
> [...]

A similar strange thing is the type evaluation in vbscript:

TypeName(window) -> HTMLWindow2
TypeName(document) -> HTMLDocument
VarType(window) -> vbObject
VarType(document) -> vbString
IsObject(window) -> True
IsObject(document) -> True

So maybe the HTMLDocument class is simply bugged?

Michael Haufe ("TNO") wrote:
> On Feb 8, 6:49 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>> I'm confused about IE's evaluation of window == document.
>> [...]
>
> A similar strange thing is the type evaluation in vbscript:
>
> TypeName(window) -> HTMLWindow2
> TypeName(document) -> HTMLDocument
> VarType(window) -> vbObject
> VarType(document) -> vbString
> IsObject(window) -> True
> IsObject(document) -> True
>
> So maybe the HTMLDocument class is simply bugged?
Possibly all nodes in the document have an internal type String.

If that is the case, then comparing two objects, where one is type
string, should result in string conversion.

window == "[object]"; // true
document == "[object]"; // true

However, document == window is false, so type conversion can only be
part of the reason.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/

On 2/8/10 7:49 PM, Garrett Smith 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.
>
> 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.

I don't see how that could work, given that a window object might
originate from another frame or window (if you care about cross-window
or cross-frame interactions).

There's always a way of duck typing with all of its consequences. You
can try that if absolutely necessary.

Interestingly, I see that in Firefox 3.6, for example, window from
another frame is `instanceof Window` where `Window` is from original
context. But Firefox behavior is hardly relevant here, of course. Just a
curious peculiarity.

--
kangax

kangax wrote:
> On 2/8/10 7:49 PM, Garrett Smith 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.
>>
>> 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.
>
> I don't see how that could work, given that a window object might
> originate from another frame or window (if you care about cross-window
> or cross-frame interactions).
>
> There's always a way of duck typing with all of its consequences. You
> can try that if absolutely necessary.
>

obj == obj.window

should always be true when obj is a window.

It will always be false when obj is not a window, unless there is a DOM
object that has a window property pointing to itself. I can't really see
why that would be the case.

obj != obj.window

should always be true when obj is not a window.

The full code:

This checkin:
http://github.com/GarrettS/ape-javas...c/dom/Event.js

Diff (can have comments added):
http://github.com/GarrettS/ape-javas...3ec07af#diff-6

Master:
http://github.com/GarrettS/ape-javas...c/dom/Event.js

Function cleanUp is added if isMaybeLeak, but that is done only when
`get` is called.

Method `get` uses function rewriting pattern, adding the returned
constructor and its prototype to the scope.

Although I haven't had much time to reflect on the design. The biggest
frustration I have had so far with it is testing it. YUI Test is only
helpful to a point.

YUI Test lacks support for dispatching focus and blur events. I added
that, added support for Apple's deplorable Touch Events API, made a few
patches, but I realize YUI Test still lacks creation of synthesized
window events, such as load/unload.

I could patch those, but then there are other pains of that API design
to deal with. One big pains is the event generation methods being so
long. When debugging, I have:
Action.click(testNode);

- and the YUI Test method for generating that event is one statement:
call another function. That other function is exceedingly long, so I
don't want to step through all of that. However, If I step over that one
statement that calls the long function, I don't get step into the
callback. Since most dom events are synchronous in browsers, I can step
keep clicking next until the browser transfers control from event
generating function to the (first) event callback for that event.
However, if I do step into that method, it is about 40 some clicks to
get to the callback. That hurts my hands and wastes time. Then there is
the issue of errors that get swallowed. Then there is the lack of stack
trace (I patched that to get it to work in a few browsers, at least).

I'd file more bugs the other bugs I've filed still haven't been fixed.
Even the patches I've submitted did not get integrated.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/