Area elements ignore the BASE element URL

VERIFIED FIXED in M12

Status

()

Core
HTML: Form Submission
P3
normal
VERIFIED FIXED
19 years ago
19 years ago

People

(Reporter: Nicholas Cull, Assigned: Eric 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

19 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)
(Reporter)

Comment 1

19 years ago
Created attachment 1970 [details]
Test case containing BASE tag and client-side image map

Updated

19 years ago
Assignee: karnaze → pollmann

Comment 2

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

Comment 3

19 years ago
Created attachment 2014 [details]
Minimized, HTML 4.0 Strict test case

Comment 4

19 years ago
Created attachment 2015 [details]
Minimized, HTML 4.0 Strict test case (second try)

Updated

19 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

19 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

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 7

19 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

19 years ago
Created attachment 2102 [details] [diff] [review]
first cut, not there yet
(Assignee)

Comment 9

19 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

19 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

19 years ago
OS: other → All
Hardware: PC → All
Target Milestone: M12
(Assignee)

Comment 11

19 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

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 12

19 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

19 years ago
Status: RESOLVED → VERIFIED

Comment 13

19 years ago
Second try test case works fine in the 1999111016 build under NT. Thanks!
You need to log in before you can comment on or make changes to this bug.