I would say rather that worrying about the status of the window, use try and
catch to attempt to access elements or variables in the new window, and keep
trying until they become available.

something like this:

var bWindowNotReady = true;
var oWindow = window.open(...);

while(bWindowNotReady){
	try{
		bWindowNotReady = oWindow.somefalsevar;
	catch(e){}
}


-----Original Message-----
From: meteorman [mailto:yhbrent@y...]
Sent: 08 January 2002 20:37
To: javascript
Subject: [javascript] RE: does IE have a readyState bug?


Advertise on P2P or become an official list sponsor.

Would you like your message to reach as many as 36,000 
professionals? Or 92,000? Or maybe even 1 million? 
Contact us (verag@w...) for more information on 
banner, button and newsletter advertising.
---
> unfortunately this isn't perfect - you need to use try and catch to handle
> the errors

Nope.  Thot of that and tried it; it does not work.  I should have added
the following to my original posting:

Some more notes:
--I am running IE 5.5 SP2 with the latest security patch installed.  My
code is supposed to run in IE 5.0+.
--I do NOT have control over any of the pages that will be loaded into the
second window, so assigning a callback function to the onLoad of those
pages is not possible.
--I have already tried putting a try-catch block inside the
detectWindowLoaded function.  This does suppress the JS error dialog box,
but it does NOT allow the JS to keep working.  Instead, the JS in the
controll window just seems to freeze.  Exceptions do not seem to work
intelligently in JS like they do in Java...

And what exactly do you mean by "this isn't perfect"?  Are you saying that
MS has fundamentally screwed up and has a buggy implementation so that what
should be a trivial property access cannot reliably be counted on?

Furthermore, I received the following in email exchanges from someone who
wishes to remain anonymous.  He is very knowledgeable about IE, and claims
that what I am seeing is due to a fundamental programming error on The
Beast's part:

*****

Basically IE does not support scripting multiple windows as well as
other browsers e.g. Netscape.

In Netscape you can keep polling a known property in the new window
that you can use to detect its readiness. Netscape does not throw
security errors there.

In IE you get erratic behavior basically because of 2 reasons:
1) the window.open() call does not block, in other words you get a
window object back before its most basic properties such as name are
ready for access without errors. The problem with this is that the
types of errors you can get with this are manifold and hard to
reproduce at the same time. For example I have never in my life seen
any of these errors on any of my machines. This fact alone has cost me
hundreds of hours in research and unsuccessful testcases.
2) Even if the new window is fully established, you get the same
errors with frames, sligtly different errors but basically the same in
nature, hard do reproduce also.

The most effective solution for this is to use callbacks from the new
window into the opener.

However it is a messy solution because you cannot get some
functionality with this that you may or may not need:
Connecting to an existing window by name by an opener that does not
yet have a handle of the new window.

.
.
.

I wrote a browser frames history module and had to finally give up
accessing ANY properties across frames - I had to rely on callbacks,
meaning that all content that participated in history had to have some
code in it that is triggered by its onload event.

These browser bugs force one into terrible design decisions.
Another example in this area is window.onload and window.onerror which
are IMHO totally screwed up because unlike their names, they are in
fact document properties, meaning that you have to re-code error and
event handlers in every page that wants its events handled by an outer
frame or global event handler.
The pity is that even people who should know better like Danny Goodman
who wrote the JavaScript bible do not agree with me.

I think you can see the whole dilemma - there is no getting out of it.
People think in terms of web pages and do not grasp the object and
component based design advantages of frames and windows.

Consequently they want to squeeze all re-usable code into some cached
.js files and at best have every page load the whole application
again. Like re-starting a word processor for every single new document
one opens during a session.
Performance issues aside multiple .js files are useless for component
based design because even in the most advanced browser, Mozilla,
strict mode debugging will not detect errors that result from invalid
re-declaration of variables across multiple .js files in the same
window.


________________________________________________________________________
Scottish Enterprise Network
http://www.scottish-enterprise.com

Headquarters Address & Contact Numbers

150 Broomielaw
5 Atlantic Quay
Glasgow
G2 8LU.
Tel:  +44 (0) 141 248 2700.
Fax:  +44 (0)141 221 3217

 This message is sent in confidence for the addressee only.
It may contain legally privileged information. The contents are not to
be disclosed to anyone other than the addressee. Unauthorised recipients
are requested to preserve this confidentiality and to advise the sender
immediately of any error in transmission.