Closed Bug 15423 Opened 25 years ago Closed 25 years ago

Area elements ignore the BASE element URL

Categories

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

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: run2000, Assigned: pollmann)

References

Details

(Whiteboard: [TESTCASE] AREA href URLs shouldn't ignore the BASE URL)

Attachments

(4 files)

Description:
   For client-side image maps, if a <BASE> tag is present in the document, all
   client-side links ignore the base URL.

What should happen:
   In the test case supplied, all area elements should resolve their URLs relative
   to the base tag in the head of the document

What actually happens:
   Mozilla ignores the base tag for the area elements

Works on:
   Opera 3.60
   Internet Explorer 5

Doesn't work on:
   Apprunner build 1999093012 (win32)
   Viewer build 1999093012 (win32)
Assignee: karnaze → pollmann
Eric, If you are doing client side image maps, please find out who is.
Summary: Area elements don't use <BASE> tag → Area elements ignore the BASE element URL
Whiteboard: [TESTCASE] AREA href URLs shouldn't ignore the BASE URL
Attached a simpler, minimized HTML 4.0 strict test case.
(Note: The 10/07/99 00:38 attachment is NOT valid, sorry about that. Please
use the attachment labeled "second try" instead.)

Appending to the original bug report:


Steps to reproduce:
 1) View the attachment "Minimized, HTML 4.0 Strict test case (second try)"
 2) Click the image.

Actual results:
  Clicking the link takes you to nonexistent URL
  http://bugzilla.mozilla.org/thanks.html

Expected results:
  Clicking the link should take you to
  http://www.netppl.fi/~sairwas/tests/BASE-AREA/thanks.html

Additional builds & platforms:
  - 1999100409 Apprunner on WinNT4 + SP5
*** Bug 16120 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Hm, okay.  I made a first stab at fixing this bug just now, and it seems to
work, but not the first time you mouse-over and click on the map, only every
time thereafter.  I'm still looking at it.  :)
Strangely, this is constructing the wrong URL the first time because
nsHTMLDocument's mBaseURL member is null the first time after viewer starts up.

This problem is not present in apprunner, so the patch I posted fixes the bug
for apprunner.  I'm trying to figure out why mBaseURL is null in viewer but not
apprunner, and why it is only null once.
My current theory is that this little dandy means to initialize mBaseURL in the
else clause, testing it out...

NS_IMETHODIMP
nsHTMLDocument::GetBaseURL(nsIURI*& aURL) const
{
  if (nsnull != mBaseURL) {
    NS_ADDREF(mBaseURL);
    aURL = mBaseURL;
  }
  else {
    aURL = GetDocumentURL();
  }
  return NS_OK;
}
OS: other → All
Hardware: PC → All
Target Milestone: M12
Okay I was wrong, after consulting Harish, he has narrowed it down to a glitch
in parser land.  CC'ing the man himself.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
I just checked in a fix for this bug.  You can test and verify it in apprunner.
Harish will be checking in a fix to the glitch I noticed with his next parser
update (he already has a fix in his local tree).
Status: RESOLVED → VERIFIED
Second try test case works fine in the 1999111016 build under NT. Thanks!
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: