Closed
Bug 37692
Opened 25 years ago
Closed 24 years ago
'Open in a New Window' on the top navbar links doesn't go to the correct url
Categories
(Core :: Layout: Images, Video, and HTML Frames, defect, P3)
Tracking
()
VERIFIED
WORKSFORME
People
(Reporter: maniak, Assigned: law)
References
()
Details
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m15)
BuildID: 2000041805
Looks like 'Open in a New Window' doesn't take into account the <BASE HREF> tag
in a document, thus messes up the address.
For example, the homepage of www.gamedata.com has a base url of
'http://www.gamedata.com/pc/', and in the top navbar, the link 'Forums' goes to
'Forums/Forums.asp'.
When opening it, it should go to 'http://www.gamedata.com/pc/Forums/Forums.asp'
and it works when opened in the same window, but when opening in a new one,
Mozilla considers 'Forums/Forums.asp' as the complete url, so doesn't find anything.
Reproducible: Always
Steps to Reproduce:
1. Load the page at http://www.gamedata.com (or
http://www.gamedata.com/pc/homepage/homepage.asp, it's the page displayed in the
frame)
2. Right-click on a link in the top navbar (Forums for example) and choose 'Open
in a New Window'
Actual Results: Mozilla opens a new window and tries to load 'forums/forums.asp'
Expected Results: Mozilla should open
'http://www.gamedata.com/pc/forums/forums.asp', taking into account the <BASE
HREF> tag.
Comment 1•25 years ago
|
||
Trying this page with the 2000-05-02-08-M16 nightly binary on WinNT,
the links in the top navbar do not work at all, which may well be bug 37578,
but relative links from all over the rest of the page open properly in a new
window relative to http://www.gamedata.com/pc/ -- note, though, that the
<BASE HREF="http://www.gamedata.com/pc/"> in the main frame (the other has no
<BODY> content) is possibly superfluous as the post-loading URL in the URL bar
is also http://www.gamedata.com/pc/ .
Leaving this bug open for now, in case the reported problem reappears when the
top navbar links start working again.
Comment 2•25 years ago
|
||
Sorry for the spam. New QA Contact for Browser General. Thanks for your help
Joseph (good luck with the new job) and welcome aboard Doron Rosenberg
QA Contact: jelwell → doronr
Comment 3•25 years ago
|
||
Retested with the 2000-06-05-08-M16 nightly binary on WinNT. Confirming as an
HTMLFrames bug.
Bug 37578 is works-for-me, including DUPs, so that can't be the problem
here. As the top links still don't work either in the same window or a new one
with Mozilla, and all other links work either way, and the top links are in
a different frame, this must be an HTMLFrames bug, at least in part, although
there may still be a urlparser bug hiding here too.
Assignee: asa → pollmann
Status: UNCONFIRMED → NEW
Component: Browser-General → HTMLFrames
Ever confirmed: true
QA Contact: doronr → petersen
Comment 4•25 years ago
|
||
-> Context menu folks. Just to be sure, am I giving these to the right guy? If
not, please let me know. Thanks!
Assignee: pollmann → law
Yes, I do the context menu. But this sounds like a problem, perhaps, with the
DOM implementation of Links. I use "link.href" and expect to get the
fully-qualified URL (and I recall fixing a bug to make it work that way a long
time ago). But I'll check it out.
Status: NEW → ASSIGNED
Comment 6•24 years ago
|
||
This appears to be working correctly. Tested with the Sept 29th build.Marking
works for me.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Updated•6 years ago
|
Product: Core → Core Graveyard
Updated•6 years ago
|
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in
before you can comment on or make changes to this bug.
Description
•