Area elements ignore the BASE element URL

VERIFIED FIXED in M12

Status

()

defect
P3
normal
VERIFIED FIXED
20 years ago
2 months ago

People

(Reporter: run2000, Assigned: pollmann)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(4 attachments)

Reporter

Description

20 years ago
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)

Updated

20 years ago
Assignee: karnaze → pollmann

Comment 2

20 years ago
Eric, If you are doing client side image maps, please find out who is.

Updated

20 years ago
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

Comment 5

20 years ago
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. ***
Assignee

Updated

20 years ago
Status: NEW → ASSIGNED
Assignee

Comment 7

20 years ago
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.  :)
Assignee

Comment 8

20 years ago
Assignee

Comment 9

20 years ago
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.
Assignee

Comment 10

20 years ago
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;
}
Assignee

Updated

20 years ago
OS: other → All
Hardware: PC → All
Target Milestone: M12
Assignee

Comment 11

20 years ago
Okay I was wrong, after consulting Harish, he has narrowed it down to a glitch
in parser land.  CC'ing the man himself.
Assignee

Updated

20 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED
Assignee

Comment 12

20 years ago
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).

Updated

20 years ago
Status: RESOLVED → VERIFIED

Comment 13

20 years ago
Second try test case works fine in the 1999111016 build under NT. Thanks!
Component: HTML: Form Submission → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.