Scripted frame fails to load new location.




19 years ago
8 years ago


(Reporter: bht237, Assigned: jst)


Windows 95

Firefox Tracking Flags

(Not tracked)



(2 attachments)



19 years ago
See attached minimal test case.
This worked before, at least in build 2000081508
See bug 49312 which is a more specialised case of this but no duplicate.

Comment 1

19 years ago
Created attachment 14252 [details]
simple test case

Comment 2

19 years ago
Works for me.  I see red in the top frame and in the bottom frame.
2000090808 on Windows 95.
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME

Comment 3

19 years ago
Reporter: Reopen or let me know if you still see this bug.

Comment 4

19 years ago
With today's build, attachment 09 [details]/08/00 04:08 works.
Reopened because other case (attached) doesn't (JavaScript error caused by
incorrect un-escaping of URL string)
See detailed description in attachment. Summary might need changing if this is a
generic JavaScript issue unrelated to frames.
Hope this helps.
Resolution: WORKSFORME → ---

Comment 5

19 years ago
Created attachment 14311 [details]
Fails with JavaScript error - second test case also works for me if I replace localhost 
with a URL that exists (I don't run a webserver). Marking WORKSFORME 20001020 
Win95. Please reopen if you disagree.

Last Resolved: 19 years ago18 years ago
Resolution: --- → WORKSFORME

Comment 7

18 years ago
Gervase, you must not alter/relax the test conditions and say it works.
It fails with a JavaScript error whether you run a local web server or not.
Although this is not required, I give you something to play with:
If you try an existing URL as you said, say
then it fails again only on column 84 instead of column 81. Re-opened.
Resolution: WORKSFORME → ---
If you don't want me to alter the test case, you need to specify exactly what I 
should be seeing with the current one. My altering was based on reading the code 
and seeing what HTML "should" work. If I got it wrong, fair enough - but you 
need to define what I should be seeing :-)


Comment 9

18 years ago
Gervase, I don't mind going through this for you. Watch me. I could add a new 
keyword "4xp" to this bug so you could see that the latest release of Netscape 
Communicator 4.x has the intended behavior (I am not doing this yet because this 
appears to be an undisputable bug).
Now you can guess that it makes sense to start your Netscape 4.x browser,
insert the URL string in the test case. Please 
load it and familiarise yourself with what you SHOULD be seeing in Mozilla.

Then please switch to Mozilla, load the test case and you will see the 
JavaScript error instead of the Netscape page exactly as documented.
I should probably mention to you that a JavaScript error is not the expected 
behavior for this case because I think the script is syntactically correct. - you are going to have to start by producing a test case that 
is legal HTML. 

For a start, I'm pretty sure that javascript: URLS should contain only 
javascript, and not HTML markup. Even if I'm wrong about that, you can't begin a 
script with </SCRIPT>, as your code seems to do:


As a more general point, if you are attaching a testcase to a bug, you also 
need an exact description of what the correct behaviour is either attached as 
a comment, or in the testcase (e.g. the testcase says "This text should be 
red."). Saying "it works in 4.x" is a pain, because if people think they see the 
same thing in both, as I did, they don't know whether the bug is fixed, or 
they've just missed the problem.

Agreed.  "try it in 4.x" is not a sufficient replacement for description of
expected and actual results.  See the bug writing guidelines at  Minimal testcases
are a great addition to a bug report but cannot be a substitution for a clear
description of the problem, the steps to reproduce, and the actual and expected
results. Also if you are going to put a description in the testcase itself,
please put that in a part of the testcase which works in mozilla.

In 4.7 (which I reinstalled on my machine to be able to interpret your testcase)
I get a page with this message in the top frame: "Localhost.COM Web Pages
If you've gotten here, and are expecting information from your local network,
your DNS is broken. Click here for common problems and solutions for DNS.
If you are looking for the SPAM lawsuit, please go to:
If you're looking for any other information, please check back or
mail us. This page is still way under construction.
To protest some really silly copyright type laws. Here are links to
and css-auth.
Matthew L. Seidl: webmaster and domain holder"
and a red bottom frame.

In Mozilla I get a blank top frame and a red bottom frame.
So I can take from this testcase that the bug is the failure of Mozilla to
display the DNS error?

Also, if the original testcase is working and this is a different issue, this
bug should be marked Worksforme and a new bug opened.  Morphing bugs makes
Verification a much more difficult process and totally breaks regression tracking.


Comment 12

18 years ago
This getting confusing. It appears that the problem is not being understood.
I take the point re morphing and will open a new bug as suggested.
Closing this one in anticipation of that event :-)

Last Resolved: 18 years ago18 years ago
Resolution: --- → WORKSFORME

Comment 14

18 years ago
Reporter is agreed to open another bug with detailed info and testcase.
You need to log in before you can comment on or make changes to this bug.