Closed Bug 290422 Opened 16 years ago Closed 15 years ago

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

Categories

(Core :: Layout, defect)

x86
Windows XP
defect
Not set
trivial

Tracking

()

RESOLVED FIXED

People

(Reporter: mike, Assigned: philor)

References

()

Details

Attachments

(3 files)

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.
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"
Assignee: firefox → nobody
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → Trunk
> 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"?
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"
And we (unlike IE) do not support <map id="foo">.

Hixie, perhaps HTML5 van clarify what to do? (Like making external image maps
impossible.)
The usage without the "#" was at one point allowed in XHTML but that has been
errataed out of the spec.
And has HTML5 seems to be referring to XHTML1.1 - not really clear - I guess
this should be clarified.
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.
So that Mozilla only supports it as an IDREF in application/xhtml+xml is a
mistake and we should have a bug on that?
> 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.
> 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?
This is about text/html atm.
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/
-> NEW per comment 11, -> me hoping it's really as simple as I think it is.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Assignee: nobody → bugzilla
Status: ASSIGNED → NEW
Attached file testcase
Attached patch patchSplinter Review
Attachment #197809 - Flags: superreview?(bzbarsky)
Attachment #197809 - Flags: review?(bzbarsky)
With that patch, how do we treat:

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

?  How do other browsers treat it?
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?
So in IE <map id="foo"> <img usemap="foo"> doesn't work?
Attached file 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 on attachment 197809 [details] [diff] [review]
patch

Compat with IE6 is quite good enough here.  r+sr=bzbarsky
Attachment #197809 - Flags: superreview?(bzbarsky)
Attachment #197809 - Flags: superreview+
Attachment #197809 - Flags: review?(bzbarsky)
Attachment #197809 - Flags: review+
Whiteboard: [checkin needed]
Landed on trunk. Does anyone feel a need to see it on the branch?
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: [checkin needed]
We shouldn't put this on branch at this late date; certainly not till a lot more
trunk baking happens...
*** Bug 322384 has been marked as a duplicate of this bug. ***
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.
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.
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?
(In reply to comment #5)
> 
> Hixie, perhaps HTML5 van clarify what to do? (Like making external image maps
> impossible.)

Done.
Depends on: 425621
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.
P.S. One author of the standard's opinion does not a standard make.
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.
OK, how about XHTML 1.0? Are you going to tell me FF3 doesn't implement that either?
XHTML 1.0, which defines usemap as a URI, not an IDREF? We sure do!
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.
How do I vote "against" this bug? I'd like to see it backed out.
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.
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.
You need to log in before you can comment on or make changes to this bug.