290422 - ''usemap'' attribute for IMG tags work without a needed "#" before inline maps.

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Mike 'Fox' Morrey]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2

Per the spec (http://www.w3.org/TR/REC-html40/struct/objects.html#adef-usemap),
"usemap" uses a URI for the value. An inline map therefor would simply be
"#mapname". However, Firefox still translates a URI with no "#" as a target
location in that document.
In other words, Firefox treats ''usemap="#map1"'' and ''usemap="map1"'' the
same, and shouldn't. The latter should cause unpredictible results (if there's
no server-side file named "map1" on the server in the current location.
The correct example is at: http://www.pandahead.com/AskMordo/  - the incorrect
is at the URI above. The map (for testing) is the skull on the "!" in the "Ask
Mordo!" logo.

Reproducible: Always

Steps to Reproduce:
1.Create HTML file with an IMAGE and a MAP
2.Link IMG to the MAP using "usemap="
3.Launch Firefox and test it. It should work. IE it won't, Opera it won't either.

Actual Results:  
Firefox acts like I clicked on the link.

Expected Results:  
Nothing to happen; no valid map specified.

No high-treatment needed for this - As a developer, you should KNOW that a "#"
is needed. When I coded a handful of pages, I had completely forgotten about
that, and having tested everything in Firefox, expected it to work, when a user
tried it and reported that they couldn't click on anything. Had to go back and
fix my idiot mistake. :) However, it's just a little thing that, for
compatibility, may cause issues in the future, or cause grief like it did to myself.

Comment 1

[Mike 'Fox' Morrey]

Fixed URI. Apologies.

Comment 2

[Phil Ringnalda (:philor)]

Doesn't seem like we're being helpful, though maybe I'm missing something. In
bug 1882 we got (limited) support for usemap="index.html#foo", but it only sees
two possibilities: either there's a "#" in the usemap value, in which case we
look for what comes after that as a map name, or there isn't, in which case we
treat the whole usemap value as being the name. The first case is as right as we
can be, but the second case seems destined to do nothing but mess with people's
expectations, since IE and Opera both just ignore usemap="foo". Seems to me like
the "if (hash > -1)" ought to have an "else return nsnull"

Comment 3

[Boris Zbarsky [:bzbarsky]]

> since IE and Opera both just ignore usemap="foo".

They do?  I was under the impression that IE allowed usemap="foo"... Or is that
the other way around and it allows <map name="#foo"> and referencing it via
usemap="#foo"?

Comment 4

[Phil Ringnalda (:philor)]

They may have allowed it at one time, but I just checked both bad forms with a
current IE and a current Opera, and nobody accepts name="#foo" usemap="#foo",
and only we accept name="foo" usemap="foo"

Comment 5

[Anne (:annevk)]

And we (unlike IE) do not support <map id="foo">.

Hixie, perhaps HTML5 van clarify what to do? (Like making external image maps
impossible.)

Comment 6

[Hixie (not reading bugmail)]

The usage without the "#" was at one point allowed in XHTML but that has been
errataed out of the spec.

Comment 7

[Anne (:annevk)]

It is in XHTML1.1:
<http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/abstract_modules.html#s_imapmodule>

The second edition doesn't change that either:
<http://www.w3.org/TR/2004/WD-xhtml-modularization-20040218/abstract_modules.html#s_imapmodule>

Comment 8

[Anne (:annevk)]

And has HTML5 seems to be referring to XHTML1.1 - not really clear - I guess
this should be clarified.

Comment 9

[Hixie (not reading bugmail)]

The HTMLWG is well-known for not updating its errata very often. However, I
assure you, this is something that was unintentionally changed during the move
to XHTML and the fact that it says IDREF in the XHTML specs is a mistake. It
should be a URI, for compatibility with HTML.

Comment 10

[Anne (:annevk)]

So that Mozilla only supports it as an IDREF in application/xhtml+xml is a
mistake and we should have a bug on that?

Comment 11

[Boris Zbarsky [:bzbarsky]]

> And we (unlike IE) do not support <map id="foo">.

We do, in XHTML (per spec).  And we don't support name="foo" in XHTML, also per
spec.  I believe this is actually correct and not affected by the IDREF/URI
issue, since URI fragment identifiers in XTHML refer to IDs.  Note that IE
generally treats id="foo" and name="foo" as identical (see its handling of
getElementById, eg).

I have no problem with removing support for usemap="foo", though.  Post a patch;
I'll review.

Comment 12

[Hixie (not reading bugmail)]

> So that Mozilla only supports it as an IDREF in application/xhtml+xml is a
> mistake and we should have a bug on that?

Isn't that this bug?

Comment 13

[Anne (:annevk)]

This is about text/html atm.

Comment 14

[Gervase Markham [:gerv] (not reading bugmail)]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 15

[Phil Ringnalda (:philor)]

-> NEW per comment 11, -> me hoping it's really as simple as I think it is.

Comment 16

[Phil Ringnalda (:philor)]

Attachment: testcase

Comment 17

[Phil Ringnalda (:philor)]

Attachment: patch

Comment 18

[Boris Zbarsky [:bzbarsky]]

With that patch, how do we treat:

  <map name="foo" id="foo">
  <img usemap="foo"> 

?  How do other browsers treat it?

Comment 19

[Phil Ringnalda (:philor)]

We say: not a link, as do IE and Opera. So we would be following Hixie's comment
9, rather than the published XHTML spec. I don't have Safari or Konqueror to
check - are they following the letter of the spec?

Comment 20

[Boris Zbarsky [:bzbarsky]]

So in IE <map id="foo"> <img usemap="foo"> doesn't work?

Comment 21

[Phil Ringnalda (:philor)]

Attachment: testcase for IDREF

id=foo, usemap=foo, IE does indeed say "not a link" (though, again, I'm a lousy
tester because I don't have IE7).

Comment 22

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 197809 [details] [diff] [review]
patch

Compat with IE6 is quite good enough here.  r+sr=bzbarsky

Comment 23

[Phil Ringnalda (:philor)]

Landed on trunk. Does anyone feel a need to see it on the branch?

Comment 24

[Boris Zbarsky [:bzbarsky]]

We shouldn't put this on branch at this late date; certainly not till a lot more
trunk baking happens...

Comment 25

[Martijn Wargers (zombie)]

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

Comment 26

[Mitch 74]

the fix prevents sites written with the correct XHTML 1.1 syntax (and using the correct mimetype) to use image maps, which breaks compatibility with all earlier Mozilla/Gecko browsers that got out starting in 2002. Isn't there a way to make Gecko accept both usemap="id" AND usemap="#id" when in full XHTML mode? This would allow cross-browser compatibility and still comply with standards.

Comment 27

[Boris Zbarsky [:bzbarsky]]

Please read the bug.   The syntax in question is no "correct XHTML 1.1 syntax" -- it's an error in the XHTML 1.1 spec and the XHTML Working Group will at some point get off their collective asses and publish the erratum.

Comment 28

[Mitch 74]

OK, then it may be a good idea to notify the w3c validator maintainers that their validator still enforces the incorrect XHTML 1.1 syntax, too; moreover, all versions of Mozilla (starting at Suite 1.0rc1 up to and including Firefox 2) will hiccup on a 'corrected' XHTML image map. Meaning that supporting all Gecko versions behaviours on image maps will require versioning support!
Isn't there a way to support both syntaxes for back/forward compatibility?

Comment 29

[Hixie (not reading bugmail)]

(In reply to comment #5)
> 
> Hixie, perhaps HTML5 van clarify what to do? (Like making external image maps
> impossible.)

Done.

Comment 30

[Skewer]

As of today, the spec still reads IDREF, the validator still fails this syntax, and my site which is 100% valid XHTML 1.1 breaks in FF3 - bug 425621. So FF3 is therefore not standards compliant, unless the standard is changed or FF3 is changed. I don't see how we can call this "fixed" personally.

Comment 31

[Skewer]

P.S. One author of the standard's opinion does not a standard make.

Comment 32

[Boris Zbarsky [:bzbarsky]]

XHTML1.1 is not really relevant here, since we don't implement it.  Once HTML5 defines this, if we're not compatible with what it does please feel free to come back to this.

Comment 33

[Skewer]

OK, how about XHTML 1.0? Are you going to tell me FF3 doesn't implement that either?

Comment 34

[Phil Ringnalda (:philor)]

XHTML 1.0, which defines usemap as a URI, not an IDREF? We sure do!

Comment 35

[Skewer]

Aha, sure enough. The validator isn't clear in that regard (putting "nav" in a URI field without "#" is valid but won't work for a client-side map).

In any case, since when doesn't Mozilla implement the XHTML 1.1 Recommendation? The Mozilla webpage indicates otherwise.

Comment 36

[Skewer]

How do I vote "against" this bug? I'd like to see it backed out.

Comment 37

[Andy Cowley]

Me too ;-) firefox/gecko is just this one bug away from supporting xhtml 1.1. Shame to force me to use css or invalid pages. booo.

Comment 38

[Boris Zbarsky [:bzbarsky]]

Andy, I'm sorry, but the XHTML working group decided to make XHTML 1.1 incompatible with XHTML 1.0.  As a result we have to pick one or the other to support, and we support XHTML 1.0.