123800 - mozilla displaying server-side imagemap

Status: RESOLVED INVALID

(Core :: Layout, defect, P2)

Description

[Lloyd Wood]

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.)

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

-> ImageLib

Comment 2

[Stuart Parmenter]

-> layout

Comment 3

[Christopher Hoess (gone)]

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

[Lloyd Wood]

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.

Comment 5

[Boris Zbarsky [:bzbarsky]]

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

[Lloyd Wood]

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
parsed.
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

[Boris Zbarsky [:bzbarsky]]

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

[Lloyd Wood]

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

[Boris Zbarsky [:bzbarsky]]

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

Comment 10

[Lloyd Wood]

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

[Boris Zbarsky [:bzbarsky]]

> but should be parsing that as a map instead.

Um... That's not what the HTML spec says about how server-side imagemaps work. 
From http://www.w3.org/TR/html401/struct/objects.html#h-13.6:

  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:

"foo?10,20"

(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

[Lloyd Wood]

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.

Clearer?

Comment 13

[Boris Zbarsky [:bzbarsky]]

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

Taking bug; this should not be that hard to do...

Comment 14

[Boris Zbarsky [:bzbarsky]]

Hmm.. So I just loaded
http://www.ee.surrey.ac.uk/Personal/L.Wood/mozilla/bug-3.html, clicked on a part
of the image not covered by an explicit imagemap area, and got taken to
http://www.ee.surrey.ac.uk/Personal/L.Wood/mozilla/pocket.map?20,31

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

Comment 15

[Lloyd Wood]

http://www.ee.surrey.ac.uk/Personal/L.Wood/mozilla/pocket.map?20,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
http://httpd.apache.org/docs/mod/mod_imap.html

Adding:
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 
default http://www.mit.edu/
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.

Comment 16

[Lloyd Wood]

Ran into this one again looking at
http://www.btimes.co.za/97/0406/tech/tech6.htm
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
http://httpd.apache.org/docs/mod/mod_imap.html

This is likely an evangelism/education issue?