Closed Bug 10479 Opened 25 years ago Closed 25 years ago

Problem with imagemap

Categories

(Core :: Graphics: ImageLib, defect, P3)

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: rwestaus, Assigned: vidur)

References

()

Details

(Whiteboard: [TESTCASE] Fix available. Waiting for tree to open.)

Attachments

(1 file)

Clicked on imagemap at bottom of page and got :

Imagemap Error

Your client did not send any coordinates. Either your client doesn't support
imagemap or the map file was not accessed as a map.

NOTE : Using NT SP 3 & Moz Mile 8
Whiteboard: [MAKINGTEST] -- run2000@geocities.com
Whiteboard: [MAKINGTEST] -- run2000@geocities.com → [TESTCASE]
This problem relates to both a client-side and a server-side image map being
used on the same image. When co-ordinates fall outside the area where the
client-side map applies, the server-side link is used, but no coordinates are
sent to the server.

There may be some debate as to what should happen when both a client-side and
server-side image map are specified -- a quick survey of the browsers here revealed the following:

Netscape 4.61: uses the client-side map unless the co-ordinate falls outside the
areas defined by the client-side map, in which case it reverts to the
server-side map.

Opera 3.60: uses the client-side map exclusively. For areas not defined in the
client side map, no action is taken.

IE 5: completely screws up. For areas defined by the client-side image map, it
jump to the server-side map without sending any co-ordinates. For areas outside
the client-side image map, it correctly sends co-ordinates to the server. In
most cases, this is useless behaviour.

Of the three behaviours, the Netscape 4.61 behaviour seems the most correct,
since it can be overridden by using a "nohref" area (see the third example in
the test case).
The third example in the test case won't work correctly while bug 7304 is
still open.

See also bug 10545, which I found while working on this test case.
Assignee: don → pnunn
QA Contact: leger → elig
Component: Browser-General → ImageLib
QA Assigning to self, and assigning to pnunn so that she sees it.



run2000, thank you for doing such an *EXCELLENT* investigation!
Assignee: pnunn → rickg
Imagemap code is in layout. I'm not sure who the owner is.
I'll reassign it to rickg and I'm sure he'll know the owner.
-pn
Assignee: rickg → vidur
V -- can you please take a look. This may belong to JOKI, in which case you
should just reassign. Thanks.
Status: NEW → ASSIGNED
Target Milestone: M10
Thanks for the investigation run2000@geocities.com. I have a fix in my tree.
Waiting for M9 to branch so I can check it in for M10.
Whiteboard: [TESTCASE] → [TESTCASE] Fix available. Waiting for tree to open.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Fix checked in on 8/19/1999. Client-side and server-side imagemaps now coexist
correctly.
[Pinged run2000 by e-mail to see if he'd like to do the verification on this,
given his greater subject knowledge and extensive bug investigation. If he'd
rather not, I'll verify it next week.]
Status: RESOLVED → VERIFIED
Verified fix. I'll go back to bug 7304 and expand on the NOHREF problems there to
make sure they get resolved.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: