window.open() causes error 80004005 on NS 7.1

[Jeff Stewart]

It seems that whenever I pass window.open() a relative URL, it fails. The
following shows up in the Netscape Javascript Console:

Error: [Exception... "Component returned failure code: 0x80004005
(NS_ERROR_FAILURE) [nsIDOMJSWindow.open]" nsresult: "0x80004005
(NS_ERROR_FAILURE)" location: "JS frame ::
http://localhost/dwm/container.html :: preloader_DoFSCommand :: line 48"
data: no]
Source File: http://localhost/dwm/container.html
Line: 48

The offending line 48 reads like this:

window.open ("images/hist001.html");

But if I run, say,

window.open ("http://www.cnn.com");

it works fine. ???

Has anyone else experienced this? I can't figure out how to fix it, and the
most recent web page that references it is back from 1999, where this is
chalked up to a bug in the development version of Netscape.

 

[Jeff Stewart]

OK, see http://www.slamdigitalworks.com/tests/windowopenproblem.html

This page exhibits the offending behavior on my system (requires Flash,
'cause that's how I discovered this problem). The first window.open()
functions properly, and the second causes an exception, listed in the
Javascript Console.

BTW, localhost is a valid hostname, and http://localhost/ is a valid URL.
On virtually all machines, the keyword "localhost" resolves to 127.0.0.1. I
use http://localhost/ to view my machine's Apache web server when testing
client sites. You can even ping localhost if you open a command prompt.

 

[DU]

OK, see http://www.slamdigitalworks.com/tests/windowopenproblem.html

This page exhibits the offending behavior on my system (requires Flash,
'cause that's how I discovered this problem). The first window.open()
functions properly, and the second causes an exception, listed in the
Javascript Console.

First you should validate your markup code with a validator. Just use a
doctype declaration
http://www.w3.org/QA/2002/04/valid-dtd-list.html
and go to
http://validator.w3.org/
There are 2 elements with the same id windowopenproblem in your code and
a name attribute also has windowopenproblem. You should also quote every
attribute value: you avoid errors and you help parsing, rendering time.
<a HREF=FSCommandpenWindow></a> just can not work.

Second, you should remove the Flash code entirely from the code since it
should have no impact on the problem. Trying to isolate what is the
problem with a rational approach to debugging assumes to eliminate as
much as possible what is not part of the problem.

Have you tried in a reduced testcase the simple
window.open("http://www.slamdigitalworks.com/tests/bad.html", "");
or
window.open("bad.html", "");

BTW, localhost is a valid hostname, and http://localhost/ is a valid URL.
On virtually all machines, the keyword "localhost" resolves to 127.0.0.1. I
use http://localhost/ to view my machine's Apache web server when testing
client sites.

Thanks for clarifying this for me: I thought so afterwards.

You can even ping localhost if you open a command prompt.
DU
--
Javascript and Browser bugs:
http://www10.brinkster.com/doctorunclear/
- Resources, help and tips for Netscape 7.x users and Composer
- Interactive demos on Popup windows, music (audio/midi) in Netscape 7.x
http://www10.brinkster.com/doctorunclear/Netscape7/Netscape7Section.html

 

[Jeff Stewart]

There are 2 elements with the same id windowopenproblem in your code and
a name attribute also has windowopenproblem.

Everything except the window.open() statements was generated by Flash. The
OBJECT and EMBED instances -must- have the same ID, or the DoFSCommand
function won't function properly. DoFSCommand is a Flash construct -- it
facilitates communication between the Flash player and Javascript. This
cannot be helped. The id of the player must match the part of the function
declaration before the underscore, otherwise the Flash player doesn't know
what function to call.

Besides, I forget which Netscape supports, OBJECT or EMBED, but the other
should just be ignored anyway.

You should also quote every
attribute value: you avoid errors and you help parsing, rendering time.
<a HREF=FSCommandpenWindow></a> just can not work.

Well, it can if the parser is written to handle it. But that
notwithstanding, I don't even know what that line does. Flash generated
that. I get the same behavior if the line is removed completely.

Second, you should remove the Flash code entirely from the code since it
should have no impact on the problem. Trying to isolate what is the
problem with a rational approach to debugging assumes to eliminate as
much as possible what is not part of the problem.

If I strip the Flash,
(http://www.slamdigitalworks.com/tests/windowopenproblem_flashless.html),
Netscape works fine. But this is moot, as the final solution -must- take
Flash into account. Whether or not it works in a "Flashless" environment is
pretty much meaningless to our project.

*sigh* At any rate, there's no reason Netscape should generate an exception
when window.open() is passed a relative URL, no matter what the
circumstances. The difference between being passed a relative or absolute
URL is trivial from a programming standpoint. Something's wrong.