Closed Bug 279588 Opened 20 years ago Closed 19 years ago

Link to a named frame opens in new window after having opend the above URL

Categories

(Firefox :: General, defect)

1.0 Branch
x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: m.bode, Assigned: bugzilla)

References

()

Details

(Keywords: qawanted)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.7.5) Gecko/20041108 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.7.5) Gecko/20041108 Firefox/1.0

Having a page consisting of three frames (named "oben", "links" and "haupt"),
where the left frame ("links") contains links. All links are referred with an
a-tag using "haupt" as target. All works fine. One of the links links to
"http://www.wuppertal.de". After opening this link for the first time,
"www.wuppertal.de" appears in the "haupt"-frame. After that, all other links
available in the "left"-frame won't open in "haupt"-frame any more, but in a
newly opened window. Reloading the page does not solve the problem. After
closing Firefox and restarting it, all works fine again, until
"www.wuppertal.de" has been displayed in the "haupt"-frame, whereafter the
problem occurs again.

Reproducible: Always

Steps to Reproduce:
See above.
Actual Results:  
See above.

Expected Results:  
Linked pages should be opened in the "haupt"-frame instead in a new window.
Well, since wuppertal.de sets window.name="wuppertal" while it loads, I would
guess that if you frame it, you no longer have a frame named haupt, you now have
one named wuppertal.
Actually, according to my references, window != frame (even if the frame class
gets most of its methods and properties inherited from the window class). So
changing the name-property of a window-object should leave the name-property of
a frame-object alone.

Even if not, and I should be wrong, the behaviour should no longer occur after
reloading the page, as at this point of time the frame/window should get its old
name back - but it does still occur after reloading. It only disappears when
restarting the browser.

And last, there are (at least) two other browsers doing what most (and also me)
users would expect them to do. Maybe there is a bug in these browsers...
mbode, can you specify the explicit steps that will show the problem at the
provided URL?

If you can, then creating a reduced testcase and attaching it to this bugfile
would be even better.
Keywords: qawanted
Extract testcase, open index.html. You will see a page consisting of 3 frames.
Click on the links 2, 3 and 4 - all will open in the main frame. After that,
open link 1. The homepage "www.wuppertal.de" will open in the main frame.

After that, open the links 2, 3 and 4 again. Now they will open in a new window
instead of opening in the main frame.
> Extract testcase, open index.html. You will see a page consisting of 3 frames.
> Click on the links 2, 3 and 4 - all will open in the main frame. After that,
> open link 1. The homepage "www.wuppertal.de" will open in the main frame.
> 
> After that, open the links 2, 3 and 4 again. Now they will open in a new window
> instead of opening in the main frame.

Thank you for the files. I examined the code. As rightly mentioned by Phil
Ringnalda, there is an inline script executing
window.name="wuppertal";
as that http://www.wuppertal.de/ webpage loads itself. So, the frame gets
renamed   from "haupt" to "wuppertal" and then your frameset index can not/no
longer find the haupt named frame.

Then 
"(...) If no such frame was found in (3), create a new window and assign it the
target name."
http://www.w3.org/TR/html401/appendix/notes.html#notes-frames
is executed. This is all correct.
All of this is the correct and intended behavior.

Workaround: change the frame name from "haupt" to "wuppertal" and then change
target="haupt" to target="wuppertal" in the links page. This will work in Deer
Park alpha 2 rv:1.8b4 20050826 and in Seamonkey 1.1a rv:1.9a1 build 20050826.

Resolving as INVALID
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: