Closed
Bug 10479
Opened 25 years ago
Closed 25 years ago
Problem with imagemap
Categories
(Core :: Graphics: ImageLib, defect, P3)
Tracking
()
VERIFIED
FIXED
M10
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
Updated•25 years ago
|
Whiteboard: [MAKINGTEST] -- run2000@geocities.com
Comment 1•25 years ago
|
||
Updated•25 years ago
|
Whiteboard: [MAKINGTEST] -- run2000@geocities.com → [TESTCASE]
Comment 2•25 years ago
|
||
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).
Comment 3•25 years ago
|
||
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.
Updated•25 years ago
|
Assignee: don → pnunn
QA Contact: leger → elig
Updated•25 years ago
|
Component: Browser-General → ImageLib
Comment 4•25 years ago
|
||
QA Assigning to self, and assigning to pnunn so that she sees it. run2000, thank you for doing such an *EXCELLENT* investigation!
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
V -- can you please take a look. This may belong to JOKI, in which case you should just reassign. Thanks.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M10
Assignee | ||
Comment 7•25 years ago
|
||
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.
Assignee | ||
Updated•25 years ago
|
Whiteboard: [TESTCASE] → [TESTCASE] Fix available. Waiting for tree to open.
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 8•25 years ago
|
||
Fix checked in on 8/19/1999. Client-side and server-side imagemaps now coexist correctly.
Comment 9•25 years ago
|
||
[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.]
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 10•25 years ago
|
||
Verified fix. I'll go back to bug 7304 and expand on the NOHREF problems there to make sure they get resolved.
Comment hidden (collapsed) |
You need to log in
before you can comment on or make changes to this bug.
Description
•