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)
Tracking
()
RESOLVED
INVALID
People
(Reporter: m.bode, Assigned: bugzilla)
References
()
Details
(Keywords: qawanted)
Attachments
(1 file)
|
1.31 KB,
application/octet-stream
|
Details |
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.
Comment 1•20 years ago
|
||
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...
Comment 3•19 years ago
|
||
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.
Comment 5•19 years ago
|
||
> 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.
Description
•