Closed Bug 51847 Opened 26 years ago Closed 25 years ago

Scripted frame fails to load new location.

Categories

(Core :: DOM: Core & HTML, defect, P3)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows 95
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: bht237, Assigned: jst)

Details

Attachments

(2 files)

simple test case
422 bytes, text/html
Details
Fails with JavaScript error
1.22 KB, text/html
Details
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.
Attached file simple test case —
Works for me. I see red in the top frame and mozilla.org in the bottom frame. 2000090808 on Windows 95.
Status: UNCONFIRMED → RESOLVED
Closed: 26 years ago
Resolution: --- → WORKSFORME
Reporter: Reopen or let me know if you still see this bug.
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.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
bht@actrix.gen.nz - 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. Gerv
Status: UNCONFIRMED → RESOLVED
Closed: 26 years ago → 25 years ago
Resolution: --- → WORKSFORME
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 http://netscape.com/index.html then it fails again only on column 84 instead of column 81. Re-opened.
Status: RESOLVED → UNCONFIRMED
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 :-) Gerv
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 http://netscape.com/index.html 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.
bht@actrix.gen.nz - 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: "<BODY bgcolor=yellow><\SCRIPT>location=\'http://home.netscape.com/index.html\'<\/SCRIP T>" 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. Gerv
Agreed. "try it in 4.x" is not a sufficient replacement for description of expected and actual results. See the bug writing guidelines at http://www.mozilla.org/quality/bug-writing-guidelines.html 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 localhost.com SPAM lawsuit, please go to: http://www.cs.colorado.edu/~seidl/lawsuit If you're looking for any other localhost.com 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 DeCSS.zip 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.
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 :-) Gerv
Status: UNCONFIRMED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → WORKSFORME
Verified. Reporter is agreed to open another bug with detailed info and testcase.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: