By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,660 Members | 1,945 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,660 IT Pros & Developers. It's quick & easy.

window.open problem on NN 7.2

P: n/a
I have an inscrutable problem with window.open. Consider the following
code:

var graphwin =
window.open("","graphWin","height=400,width=400,re sizable=yes");

It works perfectly in one place in my program. The window opens, I write
stuff to it, close the document, and it sits there like it's supposed to.

I put the identical line in a different function, which is supposed to
open the window before the first case is ever encountered, and graphwin
comes back undefined. No messages appear in the NN js console. Venkman
freaked out long ago (fails to load all the js code). I've tried putting
a graphic in the first parameter, but it doesn't help.

There are lots of bug reports about NN window.open in the archives of
this ng, but they all pertain to older versions of NN. What's really
weird is that it works in one place and not the other. The only
meaningful difference between the two functions containing the line is
that the first -- where it works -- is in a button click handler, and
the second is in a function called by an onload handler. Could it be
that NN is not quite stable while it's running onload? I also tried
using different names for the window and return variable, on the chance
that NN could not compile two different window.open statements with the
same name. Same result.

Even more bizarre (or not, depending on your experience) is that the
situation is reversed with IE 6.0; the first case fails with lots of
runtime errors that have something to do with not allowing assignment of
array objects (like var x = myarrayobject), but the second case works fine.

Any comments, please. Thanks.
Jul 23 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
Lee
Richard Trahan said:

I have an inscrutable problem with window.open. Consider the following
code:

var graphwin =
window.open("","graphWin","height=400,width=400,r esizable=yes");

It works perfectly in one place in my program. The window opens, I write
stuff to it, close the document, and it sits there like it's supposed to.

I put the identical line in a different function, which is supposed to
open the window before the first case is ever encountered, and graphwin
comes back undefined.


The window.open() method asks the windowing subsystem to create
a new window and then returns, trusting that the window will be
opened, eventually.

Depending on how busy the system is, the window may or may not
actually exist by the time you try to work with graphwin.

So, don't open blank windows and then try to write content into
them. Open them with an URI that tells the new window to reach
into the opener window to get its content:

globalHTML="<html><body><p>Hello, world!</p></body></html>";
window.open("javascript:opener.globalHTML",
"graphWin",
"height=400,width=400,resizable=yes");

Jul 23 '05 #2

P: n/a
Richard Trahan wrote:
<snip>
... . The only meaningful difference between the
two functions containing the line is that the
first -- where it works -- is in a button click
handler, and the second is in a function
called by an onload handler. ... <snip>

That is precisely the distinction that Gecko browsers use to
discriminate between requested and non-requested pop-ups. If it doesn't
directly follow form user interaction it is an unrequited pop-up and the
default behaviour of the pop-up blocker is to block it (though I would
expect the value returned form the window.open call to be null not
undefined).

If it is a problem for you then disable the pop-up blocking in your
browsers. If you don't want it to be a problem for the visitors to some
site you are creating then abandon the opening of new windows.
Even more bizarre (or not, depending on your experience)
is that the situation is reversed with IE 6.0; the first
case fails with lots of runtime errors that have something
to do with not allowing assignment of array objects (like
var x = myarrayobject), but the second case works fine.


That is far too unspecific to be commented upon (but it is probably
naming collisions on the global object).

Richard.
Jul 23 '05 #3

P: n/a
Lee wrote:
(snip)
So, don't open blank windows and then try to write content into
them. Open them with an URI that tells the new window to reach
into the opener window to get its content:

globalHTML="<html><body><p>Hello, world!</p></body></html>";
window.open("javascript:opener.globalHTML",
"graphWin",
"height=400,width=400,resizable=yes");

Thank you for responding.

Although your suggestion did not solve the problem, I remember reading
this in another post, and I have incorporated it into my code. My
problem was partially solved by Richard Cornford; see my reply to him.
Jul 23 '05 #4

P: n/a
Richard Cornford wrote:

(snip)
If it is a problem for you then disable the pop-up blocking in your
browsers. If you don't want it to be a problem for the visitors to some
site you are creating then abandon the opening of new windows.

That is far too unspecific to be commented upon (but it is probably
naming collisions on the global object).


Thank you for responding. Yes, it was the pop-up blocking that was
causing the problem, in part. The blocker also prevents window.open from
a keystroke handler, which began working when I disabled popups.

But not for long. Everything broke after a few tries, but when I
restarted NN 7.2, it worked again. This ng has had reports of memory
leaks with window.open; also, I am using Windows 98, which is notorious
for resource leaks, especially GD (Graphics Device) handles. One of my
window.open uses writes GD-intensive stuff to the window, and I suspect
that's causing the failure. The error message I get from the NN js
console window is:

Error: uncaught exception: [Exception... "Component returned failure
code: 0x80004005 (NS_ERROR_FAILURE) [nsIControllers.removeController]"
nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame ::
chrome://navigator/content/navigator.js :: Shutdown :: line 736" data: no]

I have no idea how to interpret that.
Jul 23 '05 #5

P: n/a
Richard Trahan wrote:
<snip>
Thank you for responding. Yes, it was the pop-up blocking
that was causing the problem, in part. The blocker also
prevents window.open from a keystroke handler, which began
working when I disabled popups.

But not for long. Everything broke after a few tries, but
when I restarted NN 7.2, it worked again. This ng has had
reports of memory leaks with window.open; also, I am using
Windows 98, which is notorious for resource leaks, especially
GD (Graphics Device) handles. One of my window.open uses
writes GD-intensive stuff to the window, and I suspect
that's causing the failure. The error message I get from
the NN js console window is:
The danger with fixating on what you believe to be the cause of your
problems is that you might be wrong and end up missing having an error
(or inadvisable practice) identified in your actual script. And then you
ill also assume a similar cause when you next repeat that mistake.

It takes a reproducible demonstration of the problem before any single
cause can be attributed (or, at least, other possible causes
eliminated).

Error: uncaught exception: [Exception... "Component returned
failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIControllers.
removeController]" nsresult: "0x80004005 (NS_ERROR_FAILURE)"
location: "JS frame :: chrome://navigator/content/navigator.js
:: Shutdown :: line 736" data: no]

I have no idea how to interpret that.


It is an exception thrown by code in a file called "navigator.js" that
is part of the browser's internal JS. Maybe a consequence (side effect
of) your code, maybe a browser bug that is just a coincidence.

But you haven't said anything about the errors you mentioned with IE,
and they speak of erroneous code and should be fixed before any wider
conclusions are drawn.

Richard.
Jul 23 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.