Visit this URL for a sample server-side image map (it's a map of the south bay area) that does not work in NGLayout, but works in Navigator.

Vidur, do you know who would be responsible for this?

Adding back in the URL field. Apparently all the URLs were trashed in the migration fron bugsplat to bugzilla.

I don't know who's responsible. I believe Kipp did client-side image maps. I suspect Tom Pixley might be interested since it involves some event processing. Sparky should be involved, just because I know it will annoy him. Could one of you guys take this bug.

Adding the victims Vidur mentioned to the CC list in hopes one of them will pick up this bug, and changing component field to "Form Submission" for lack of a better component.

Reassigning to Chris since this seems like a forms thing, and since no one else has been able to take a look at this, maybe Chris can.

Setting all current Open/Normal to M4.

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Although component says 'Form Submission' looks like an imagemap problem. Reassigning qa contact to elig@netscape.com

*** Bug 4034 has been marked as a duplicate of this bug. ***

bug 4034 was marked as a duplicate of this and here are its comments. At the Apple Store page, click on an item (say, the iMac) to get more info on it. I'm guessing that expected behavior is to send the screen coordinates directly to the server (by appending them to the URL specified in ths link). Instead, however, all that happens is that the image itself is displayed in the browser and the link is not followed. The following HTML snippet may be of use: <A href="http://store2.apple.com/1-800-795-1000/WebObjects/AppleStore.woa/256775609 0968574907028295232613155/CoverPage.wo/44151854015155/2.1.3.0.0.0/1/order7.apple .com?57,91"><IMG height="166" vspace="0" alt="Special" width="180" border="0" align="middle" ismap src="menuspecialpbg3.jpg"></A> Clicking on this link doesn't follow the link, but instead displays the image source in the browser. If you remove the 'ismap' from the link, it works as expected. This HTML does work in Nav 4.51 and IE 4.01.

Marking M5

*** Bug 3951 has been marked as a duplicate of this bug. ***

*** Bug 6138 has been marked as a duplicate of this bug. ***

*** Bug 5113 has been marked as a duplicate of this bug. ***

Redistributing to M8...

*** Bug 7738 has been marked as a duplicate of this bug. ***

The offending code seems to be in (or very very near): mozilla/layout/html/base/src/nsImageFrame.cpp::HandleEvent nsIURL* docURL = nsnull; nsIDocument* doc = nsnull; mContent->GetDocument(doc); if (nsnull != doc) { docURL = doc->GetDocumentURL(); NS_RELEASE(doc); } NS_ASSERTION(nsnull != docURL, "nsIDocument->GetDocumentURL() returning nsnull"); PRBool inside = PR_FALSE; if (nsnull != docURL) { inside = map->IsInside(x, y, docURL, absURL, target, altText, &suppress); } NS_IF_RELEASE(docURL); if (inside) { // We hit a clickable area. Time to go somewhere... PRBool clicked = PR_FALSE; if (aEvent->message == NS_MOUSE_LEFT_BUTTON_UP) { aEventStatus = nsEventStatus_eConsumeDoDefault; clicked = PR_TRUE; } TriggerLink(aPresContext, absURL, target, clicked); } This is the stuff that handles Server Side image maps like this one.

*** Bug 8498 has been marked as a duplicate of this bug. ***

*** Bug 8498 has been marked as a duplicate of this bug. ***

*** Bug 8498 has been marked as a duplicate of this bug. ***

If I had no fear of breaking image maps, I would hack in code to get the containing <A>'s HREF in this case instead of using the nsImageFrames's mContent's BaseURL. As it is though, well... I just don't know how horribly this might break things. Who should this bug should go to? Hmm, lxr tells me Peter originally wrote the offending "htmlContent->GetBaseURL" just a few lines below what I quoted earlier, so I'm giving it to him. (I guess I felt too guilty to pass the buck at that time, but now I have more bugs then even Peter, so there. ;) )

Apparently the issue isn't really related to GetBaseURL (which is a cover for <BASE> tag compatibility glue), but a deficiency in the image map code not taking into account hrefs from enclosing <A> tags. Kipp any insight?

There were two bugs (1) the coordinates for server side image maps were not bein properly computed (2) the wrong url was being computed. Now, what is done is that the image code looks upward in the content tree for an html anchor element and if it finds one, uses the href attribute from there.

Verified fixed in 7.13.99 AM builds (via img_ismap HTML test case), on Win NT 4.0SP3, Mac OS 8.6, and Linux.