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)

x86
Windows 2000
defect

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.
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.
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
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
-> 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
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
Marking verified works for me.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
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.