Prev: Would you stop for a moment?!
Next: What’s the best way to solve this kind of javascript dead loop?
From: "Michael Haufe ("TNO")" on 9 Feb 2010 21:16
On Feb 8, 6:49 pm, Garrett Smith <dhtmlkitc...(a)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?
From: Garrett Smith on 9 Feb 2010 21:22
Michael Haufe ("TNO") wrote:
> On Feb 8, 6:49 pm, Garrett Smith <dhtmlkitc...(a)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/
From: kangax on 10 Feb 2010 02:05
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
From: Garrett Smith on 11 Feb 2010 14:49
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-javascript-library/blob/e85500d29e9c699d3224bb137a18267813ec07af/src/dom/Event.js

Diff (can have comments added):
http://github.com/GarrettS/ape-javascript-library/commit/e85500d29e9c699d3224bb137a18267813ec07af#diff-6

Master:
http://github.com/GarrettS/ape-javascript-library/blob/master/src/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/
From: kangax on 11 Feb 2010 17:54
On 2/11/10 2:49 PM, Garrett Smith wrote:
> 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

Doesn't have to be a DOM object. Could be any object that has `window`
property referencing object itself.

(function(){
var o = { };
o.window = o;
return (o.window == o); // true
})();

> why that would be the case.
>
> obj != obj.window
>
> should always be true when obj is not a window.

Well, in IE `window === window` is false. Where's guarantee that `window
== window` won't be false either?

But then again, as it stands now, I don't see a safe way to detect
window in cross-browser manner, and avoid chance of false positives
(it's either duck-typing or self-referencing comparison like the one you
mention; both can fail).

>
> The full code:
>
> This checkin:
> http://github.com/GarrettS/ape-javascript-library/blob/e85500d29e9c699d3224bb137a18267813ec07af/src/dom/Event.js
>
>
> Diff (can have comments added):
> http://github.com/GarrettS/ape-javascript-library/commit/e85500d29e9c699d3224bb137a18267813ec07af#diff-6
>
>
> Master:
> http://github.com/GarrettS/ape-javascript-library/blob/master/src/dom/Event.js
>
>
> Function cleanUp is added if isMaybeLeak, but that is done only when
> `get` is called.

Why not avoid cleanup completely?

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

Have you considered writing your own testing lib?

[...]

--
kangax
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?