mozilla displaying server-side imagemap




16 years ago
7 years ago


(Reporter: Lloyd Wood, Assigned: bz)



Firefox Tracking Flags

(Not tracked)





16 years ago
A client-side imagemap with server-side map fallthrough can make mozilla display
the server-side imagemap if the client-side imagemap lacks a shape=default.

This is something of a change in behaviour from Netscape. If there's no ISMAP
tag, following the HREF is fine. If there's an ISMAP and we're in quirks mode,
it's not what I would expect.

(and are login email addresses now lower-case only? I had a devil of a time
logging in.)
-> ImageLib
Assignee: asa → pavlov
Component: Browser-General → ImageLib
QA Contact: doronr → tpreston

Comment 2

16 years ago
-> layout
Assignee: pavlov → attinasi
Component: ImageLib → Layout
QA Contact: tpreston → petersen
Uh, why does ismap "suggest that's a bad idea"?  I realize the current method
isn't backwards-compat with NS4.x, but it doesn't seem out of the bounds of
reasonable interpretation, either...

Comment 4

16 years ago
The ISMAP tag indicates that the enclosing HREF link is to the imagemap itself,
not to a default link to be followed. Thus, following the link and displaying
the imagemap content is a bad idea and (as the ISMAP tag indicates) should be
avoided; if the imagemap specifies no default behaviour, do nothing instead when
the user clicks on a default region.


16 years ago
Ever confirmed: true


16 years ago
Priority: -- → P3
Target Milestone: --- → Future

Comment 5

15 years ago
So the question is, is this quirk something that would affect enough sites to
make it worth the complexity and code needed to implement it?  My feeling is "no".

Comment 6

15 years ago
I'm not sure that my mentioning of quirks mode makes it a 'quirk'.

The ISMAP tag indicates how (and that) the surrounding HREF content should be
Internet Explorer doesn't have this problem; IE is fundamentally better at
image-map handling.
Lynx is better at rendering loaded image maps into a list of text links.

Comment 7

15 years ago
The problem is that the entire definition of ISMAP is fundamentally incompatible
with the DOM event model.  There is a click.  This click bubbles. If it bubbles
up to the <a>, the <a> will be followed.

Unless we want to make the case that an image which has an imagemap should
cancel click events even in cases when the click is on an inactive area (bizarre
definition of "inactive").

Comment 8

15 years ago
It's how it bubbles. You don't necessarily want to cancel the click, but could
interpret the href in light of the ISMAP tag.

I'd expect fallthrough from client-side imagemap to server-side imagemap if the
point clicked is unspecified in client-side usemap. The maps don't have to be
identical; you could have static areas in the client-side map, and dynamic areas
elsewhere in the server-side map. Under the current behaviour, that sort of
elegance is simply not possible.

Comment 9

15 years ago
Ah, ok.  So you just want server-side imagemap support in general.  Sure.  Can do.

Comment 10

15 years ago
You've got it - the fallthrough of an unspecified default in the client map is
simply the most obvious case of this client-to-server-side map fallthrough
failing, and it should be supported.

We shouldn't be falling through to displaying the server-side map, but should be
parsing that as a map instead. (Think of the client map as a layer in front of
the server map layer in front of the image, if that helps. Right now, you can
have either a single client or server-side layer in front of the image, but you
can't layer them together.)

Comment 11

15 years ago
> but should be parsing that as a map instead.

Um... That's not what the HTML spec says about how server-side imagemaps work. 

  Server-side. When a user activates a region of a server-side image map with a
  mouse, the pixel coordinates of the click are sent to the server-side agent
  specified by the href attribute of the A element. The server-side agent
  interprets the coordinates and performs some action.

So if you have:

<a href="foo"><img ismap></a>

And I click at the point (10, 20) on the image, Mozilla should just load:


(resolving it relative to the document base URI, of course).

What exactly gave you the idea that the _client_ has anything to do with the
processing of _server_ side imagemaps?  Is there something I'm missing here?  Or
is this just a "you should do what IE does" kinda thing?

Comment 12

15 years ago
oops, mea culpa - replace 'parsing' with 'treating'.

In the default case I opened this on, the click ?x,y on an unspecified region is
not being passed through to the server-side map.

I'm arguing that if the clicked coordinates aren't covered by a region in a
client-side map (i.e. there is no default region, which otherwise covers
everything that is left) and a server-side map is specified (ismap and a href)
then those coordinates should be passed through for server-side processing.



Comment 13

15 years ago
OK, that's what I thought you meant, till comment 10.  ;)

Taking bug; this should not be that hard to do...
Assignee: attinasi → bzbarsky
OS: Linux → All
Priority: P3 → P2
Target Milestone: Future → mozilla1.4beta

Comment 14

14 years ago
Hmm.. So I just loaded, clicked on a part
of the image not covered by an explicit imagemap area, and got taken to,31

This seems correct to me.  What is the problem again, exactly?

Comment 15

14 years ago,31

displayed onscreen in mozilla the imagemap contents themselves (and certainly
does that in 1.4b). You should not be able to read the server-side map onscreen.

Turns out that this is because Apache has deprecated default use of mod_imap

AddHandler imap-file map 
to the .htaccess of a parent directory fixed that.

Turns out that was confusing me on how client-side/server-side worked; I just added 
to the server-side map in the example. With AddHandler working right, clicking
on a background area unspecified in the client map takes us to the server map,
and to the MIT homepage. That's not specified in the client map, so
client/server fallthrough is actually working how I imagined it should anyway.

Marking this bug as invalid.
Last Resolved: 14 years ago
Resolution: --- → INVALID

Comment 16

7 years ago
Ran into this one again looking at
and clicking on the imagemapped buttonbar - Apache server, map is served out rather than parsed, again because Apache has deprecated default use of mod_imap

This is likely an evangelism/education issue?
You need to log in before you can comment on or make changes to this bug.