Last Comment Bug 1882 - Treat USEMAP attribute values as URI data rather than CDATA or IDREF
: Treat USEMAP attribute values as URI data rather than CDATA or IDREF
: compat, testcase, topembed+
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
: P3 normal with 2 votes (vote)
: mozilla1.3beta
Assigned To: Heikki Toivonen (remove -bugzilla when emailing directly)
: Chris Petersen
: Jet Villegas (:jet)
: 15311 40886 74867 102849 102851 110157 113155 126982 131543 183541 185225 (view as bug list)
Depends on:
Blocks: html4.01 189643
  Show dependency treegraph
Reported: 1998-12-11 17:38 PST by Doug Sheppard
Modified: 2004-04-26 07:52 PDT (History)
21 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

HTML fragment with image referencing USEMAP from another document (49 bytes, text/html)
1999-07-07 20:32 PDT, Doug Sheppard
no flags Details
Contains imagemap for test case (113 bytes, text/html)
1999-07-07 20:33 PDT, Doug Sheppard
no flags Details
100x100 GIF image, in case you don't have one handy for testcase (148 bytes, image/gif)
1999-07-07 20:34 PDT, Doug Sheppard
no flags Details
Potential fix (4.17 KB, patch)
2003-01-10 15:02 PST, Heikki Toivonen (remove -bugzilla when emailing directly)
no flags Details | Diff | Splinter Review
Fix v2 (4.76 KB, patch)
2003-01-15 10:31 PST, Heikki Toivonen (remove -bugzilla when emailing directly)
roc: review+
roc: superreview+
Details | Diff | Splinter Review
Patch for 2003-01-19-18-trunk to fix the StaticBuild (573 bytes, patch)
2003-01-19 23:08 PST, Roland Mainz
netscape: review+
dmose: superreview+
Details | Diff | Splinter Review

Description Doug Sheppard 1998-12-11 17:38:47 PST
The USEMAP attribute should be able to point to any legal URI, not just a
fragment.  In current practice with most browsers, including NGT, only fragments
are supported.  (Tested with viewer.exe from Dec 10/98 Win95 build.)

Refer to the URL above for a question relating to this behaviour, including a
link to a document exhibiting the problem.
Comment 1 kipp 1999-01-08 12:02:59 PST
I've marked this as an enhancement request since its not yet supported in other
browsers. We *should* do it, its just lower priority.
Comment 2 Paul MacQuiddy 1999-03-05 22:06:59 PST
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at
Comment 3 Doug Sheppard 1999-05-05 14:37:59 PDT
The original URL has disappeared from the face of the earth, so I've removed it.
Comment 4 Hixie (not reading bugmail) 1999-05-23 12:57:59 PDT
Documentation for the USEMAP feature is in the HTML specification:

Note that this feature is required for a 100% HTML4 implementation.
Comment 5 gerardok 1999-05-24 10:47:59 PDT
Miscategorized as enhancement. It's a bug. Severity changed back to Normal.
Comment 6 Doug Sheppard 1999-07-07 20:32:59 PDT
Created attachment 744 [details]
HTML fragment with image referencing USEMAP from another document
Comment 7 Doug Sheppard 1999-07-07 20:33:59 PDT
Created attachment 745 [details]
Contains imagemap for test case
Comment 8 Doug Sheppard 1999-07-07 20:34:59 PDT
Created attachment 746 [details]
100x100 GIF image, in case you don't have one handy for testcase
Comment 9 Doug Sheppard 1999-07-07 20:37:59 PDT
Unless anyone can come up with a simpler test, I think the three attachments I
just posted are a minimal test case.  Save 20:32 as map1.html,, 20:33 as
map2.html, and 20:34 as map1.gif.  This does work with Lynx 2.8.2, but M7
doesn't even give a pointy-hand cursor for me.
Comment 10 kipp 1999-07-08 14:17:59 PDT
Umm, reverted back to an ehancement request. Since I use the bug prioritize *my*
bugs, stop messing it with please.
Comment 11 Doug Sheppard 1999-07-30 14:27:59 PDT
(Sigh.  Do you think I'd notice that my address wasn't in the status line while
I was building the test case?  But that gives me a chance to mention:)

kipp, I'm not going to change the priority on you but I do think this does now
qualify as a bug, not an enhancement.  Lynx 2.8.2 does properly handle maps on
separate pages, and this is still a checklist item for 100% HTML4.0 compliance..
Comment 12 kipp 1999-09-21 20:11:59 PDT
I read the spec, and it doesn't indcate to me that it should behave as you
suggest. In particular, there is nothing in there that indicates what a
conformant user agent should do with the URI present in the USEMAP attribute.
This is not a case of "reading between the lines" because to reference another
URI implies a file format and a set of rules for processing the file. None of
that is in the spec.

Using a URI that is relative to the current document (e.g. #map-name) is
supported, and represents the overwhelmingly largest usage of client-side image

I'm marking this wont-fix. Feel free to change it to invalid if you agree with
my spec analysis.
Comment 13 Hixie (not reading bugmail) 1999-09-27 07:48:59 PDT
Good point. The spec doesn't actually suggest that the target of the usemap
attribute can lie outside the current document. However, it doesn't actually
say that it can't, either.

So we could implement this feature, without breaking the spec. So instead of
marking it WONTFIX, I'm going to mark it LATER (i.e., lets look at this again
for a later version.)
Comment 14 Nicholas Cull 1999-10-03 00:24:59 PDT
*** Bug 15311 has been marked as a duplicate of this bug. ***
Comment 15 buster 2000-03-06 11:50:32 PST
mine now
Comment 16 buster 2000-03-06 17:20:42 PST
resetting later resolution accidentally removed
Comment 17 Hixie (not reading bugmail) 2000-06-07 10:19:54 PDT
Reopening and moving to Future...
Comment 18 Hixie (not reading bugmail) 2000-06-14 11:56:57 PDT
Erm, _really_ reopening...
Comment 19 Hixie (not reading bugmail) 2000-12-11 16:15:21 PST
Upon managerial request, adding the "testcase" keyword to 84 open layout bugs that
do not have the "testcase" keyword and yet have an attachement with the word
"test" in the description field. Apologies for any mistakes.
Comment 20 Fabian Guisset 2000-12-22 09:32:58 PST
*** Bug 40886 has been marked as a duplicate of this bug. ***
Comment 21 Greg K. 2001-02-14 00:47:43 PST
FWIW, I'm pretty sure this feature was present in Mac IE 4.5, though it
apparently went extinct in their 5 product.
Comment 22 Greg K. 2001-02-14 00:49:23 PST
For the hell of it, an easily accessible testcase is available at
"". I always wanted to see this
feature work *somewhere*. :)
Comment 23 Daniel J. Peng 2001-03-21 21:13:27 PST
There is more to this bug, and at , this bug is
actually a problem.  The IMG tags have attributes like
usemap="index.htm#ImageMap24200" . Even though both the IMG and MAP tags are on
index.htm, Mozilla 0.8 and Netscape 4.76 (both on RedHat 7) do not use the
imagemaps, apparently because the document filename is specified.  I suspect
this can be fixed without fully supporting imagemaps on external documents.

The second problem is that you can access as .  Handling this case seems to be difficult without fully
implementing imagemaps on external documents.

Curiously, Internet Explorer 5 (Windows 95, 98, 2000) renders the imagemaps as
intended from both and . I
suspect that it is breaking standards, though.  If accessing gave you spamspamspamspam.htm instead of index.htm, I
think IE5 would probably use the imagemaps as if the document were index.htm . 
I haven't tried this, though.

With regards to standards compliance, the HTML 4.01 Strict DTD at says, underneath the definition and
attributes of the IMG element:

<!-- USEMAP points to a MAP element which may be in this document
  or an external document, although the latter is not widely supported -->

HTML 4.01 thus *requires* support for imagemaps in an external document.
Comment 24 Hixie (not reading bugmail) 2001-03-25 17:13:58 PST
iirc, comments in the DTD are considered non-normative
Comment 25 Hixie (not reading bugmail) 2001-04-02 17:02:04 PDT
See also bug 51339.
Comment 26 Braden 2001-08-27 11:27:21 PDT
This is not an enhancement. It is needed for spec compliance. The argument that
the HTML spec doesn't specifically state that USEMAP can be any valid URI does
not hold water. The value for USEMAP is described as a URI, and we should not
assume restrictions that are not in the spec.
Comment 27 Christopher Hoess (gone) 2001-10-03 12:25:23 PDT
*** Bug 102851 has been marked as a duplicate of this bug. ***
Comment 28 Marc Attinasi 2001-10-03 15:08:04 PDT
The spec is pretty clear to me. It says (for the usemap attribute):

This attribute associates an image map with an element. The image map is defined
by a MAP element. The value of usemap must match the value of the name attribute
of the associated MAP element.

in particular, read the last sentance again. the value must match the value of a
name attribute on a MAP element. Where does it say that it can be an arbitrary
URI that potentially references a map on some other part of the web? Just
because it takes a URI value does not mean than any legal URI is legal there.

If we were to fix this, I think it would have to be in Quirks mode only, to
follow IE's (currently proprietary) interpretation of the usemap attribute.
Comment 29 Marc Attinasi 2001-10-03 15:08:33 PDT
accepting since buster is not on the project anymore.
Comment 30 Greg K. 2001-10-03 15:21:44 PDT
Marc, that's probably a valid interpretion of the specification. Unfortunately,
the specification fails anyway because USEMAP attribute values contain not only
the value of the NAME attribute of the map, but are always preceded by the "#"

I believe that this implies URI handling for the USEMAP attribute value. And, in
fact, the attribute definition for USEMAP in the DTD specifies that it holds a
URI data type. (See [].)

I think what we have to do in this case is decide which is more important; the
DTD definition, or a vaguely-worded paragraph that appears to somewhat
contradict it? And, I think it's clear we must give more precedence to the DTD
definition, since the paragraph contradicts standard practice.
Comment 31 Greg K. 2001-10-03 15:25:29 PDT
In fact, that paragraph should probably be reworded as follows in order to be
consistent with its' own DTD:

"This attribute associates an image map with an element. The image map is defined
by a MAP element. The value of usemap must address, via a URI, a named MAP element."
Comment 32 Marc Attinasi 2001-10-04 17:56:16 PDT
Good points, Greg. I drop my assertion that this is Quirks only behavior. In
fact, it might be worht a littel clarification from the HTML WG - I'll post to
their public list.
Comment 33 Susie Wyshak 2001-10-10 13:46:45 PDT
Any insight into why the "space map" image map doesn't work on this page? I 
thought it might be related to this bug.

Always reproducible.
Occurs on Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) 

Works ok in Netscape 4.7 & IE. 
Comment 34 Susie Wyshak 2001-10-10 13:54:33 PDT
The answer is as I suspected and is in
so please disregard. Thanks.
Comment 35 Marc Attinasi 2001-10-11 16:29:42 PDT
OK, the HTML working group says:

'This is an erratum, it's defined as URI (URI reference, actually...)'

So, we need to support maps on other pages. Cool. Updating milestone and priority.
Comment 36 Greg K. 2001-10-11 16:58:31 PDT
I have updated my testcases at [] with both
Quirks (HTML 4.0 Transitional) and Strict (XHTML 1.0 Strict) versions. Any patch
must apply to both.
Comment 37 Greg K. 2001-10-11 17:28:59 PDT
Also, it may be wise to include people associated with such technologies as DOM,
XLink, XPath, and XPointer for their input on this.
Comment 38 Greg K. 2001-11-08 15:14:10 PST
Removing HTML4 keyword as USEMAP attributes as URI or URL values has existed
since HTML 3.2.

(In truth, this should get an html32 keyword, as it regards a bug in Mozilla's
compliance with that specification. Unfortunately, no such keyword exists.)
Comment 39 Christopher Hoess (gone) 2001-11-08 18:47:45 PST
Replacing html4 keyword. Whether or not it was in HTML 3.2 is irrelevant to the
fact that it blocks HTML 4.01.
Comment 40 Christopher Hoess (gone) 2001-11-10 17:14:27 PST
*** Bug 74867 has been marked as a duplicate of this bug. ***
Comment 41 Christopher Hoess (gone) 2001-11-10 17:15:19 PST
*** Bug 102849 has been marked as a duplicate of this bug. ***
Comment 42 Boris Zbarsky [:bz] (still a bit busy) 2001-11-17 11:28:09 PST
*** Bug 110157 has been marked as a duplicate of this bug. ***
Comment 43 rubydoo123 2001-11-19 17:40:31 PST
Hopefully this isn't offensive to anyone, but I am removing the note in the 
whiteboard about compliance:  [This is a fault in Mozilla's HTML 3.2 compliance]

If you want it readded, please do so and I'll not remove it again
Comment 44 Koike Kazuhiko 2001-12-02 14:07:50 PST
*** Bug 113155 has been marked as a duplicate of this bug. ***
Comment 45 Christopher Hoess (gone) 2002-01-29 00:06:29 PST
To further confuse matters, XHTML 1.1 changes this from "%URI" to "IDREF", so that only links internal to the document are supported in XHTML 1.1.
Comment 46 Greg K. 2002-01-29 00:29:08 PST
Sigh. How fun.

Christopher, URI?

I must say I'd be surprised if an "IDREF" data type couldn't refer to an ID in
an external document.
Comment 47 Christian Schmidt 2002-01-31 15:19:22 PST
Quote from

>     'usemap' points to the 'id' attribute of a <map> element,
>     which must be in the same document; support for external
>     document maps was not widely supported in HTML and is
>     eliminated in XHTML.

Note that it is still legal to refer to a map element using an absolute or 
relative URI, e.g. "file.html#map" from within file.html. This is supported by 
NS4 and IE6 but not by Mozilla (see bug 113155).
Comment 48 Greg K. 2002-01-31 22:17:34 PST
<Editorial>A stupid decision. The XHTML WG has basically deprecated client-side
maps in favor of the old server-side maps. Nobody's going to do serious
client-side work this way.</Editorial>
Comment 49 timeless 2002-02-22 03:35:17 PST
*** Bug 126982 has been marked as a duplicate of this bug. ***
Comment 50 Greg K. 2002-02-23 14:06:54 PST
That notwithstanding, this still will need to be done for HTML 3.2 through HTML
4.0.1 and XHTML 1.0.
Comment 51 Jacek Piskozub 2002-03-18 06:24:23 PST
*** Bug 131543 has been marked as a duplicate of this bug. ***
Comment 52 Asa Dotzler [:asa] 2002-03-27 17:45:40 PST
not critical for 1.0
Comment 53 Christopher Hoess (gone) 2002-04-09 22:09:10 PDT
Apparently the HTML WG now plans to release an erratum returning the usemap
attribute to URI, rather than IDREF.
Comment 54 Greg K. 2002-04-09 22:46:24 PDT
That's good news; thanks, Christopher. Do you have a URL or other reference to
that news?
Comment 55 Christopher Hoess (gone) 2002-05-23 06:02:37 PDT
Comment 56 Boris Zbarsky [:bz] (still a bit busy) 2002-12-04 13:38:43 PST
*** Bug 183541 has been marked as a duplicate of this bug. ***
Comment 57 Boris Zbarsky [:bz] (still a bit busy) 2002-12-13 12:24:19 PST
*** Bug 185225 has been marked as a duplicate of this bug. ***
Comment 58 Bob Clary [:bc:] 2002-12-16 10:38:29 PST
To summarize (please correct me if I am wrong): this is a bug in our
implementation of HTML 3.2-HTML 4.01, XHTML 1.0 and XHMTL 1.1 with the errata.
We are not backwards compatible for internal maps which include the filename.
This should be fixed not only in quirks but also standards mode. 

Can we get this fixed for 1.3?
Comment 59 Michael Buckland 2002-12-18 10:16:51 PST
Discussed in edt.  Plussing and reassinging to saari to determine if we can get
in for 1.3
Comment 60 David Epstein 2002-12-18 10:39:18 PST
Comment 61 saari (gone) 2003-01-06 16:37:52 PST
this should go to content folks
Comment 62 Heikki Toivonen (remove -bugzilla when emailing directly) 2003-01-06 16:41:27 PST
I can try to take this on...
Comment 63 Heikki Toivonen (remove -bugzilla when emailing directly) 2003-01-10 15:02:58 PST
Created attachment 111239 [details] [diff] [review]
Potential fix

This patch makes it so that we get the ref part of the URI in usemap attribute,
or the whole attribute if there is no '#' character, when trying to find the
map element. We only search from the current document, not from external

I put testcases up at (Netscape internal

Currently this patch crashes for me if I do depend builds. Trying clobber now
to see if it helps. If not, then I probably goofed somehow with the patch...
Comment 64 Greg K. 2003-01-10 15:24:27 PST
Will the final version handle external documents as well?
Comment 65 Heikki Toivonen (remove -bugzilla when emailing directly) 2003-01-10 15:41:06 PST
No, external documents will not be handled.

There are significant difficulties in implementing support for external
documents. I don't think we even have architecture in place to load HTML
synchronously in the background. Even if we did, it would take a user-noticeable
amount of time to load those external files, and we would also need to store
those files which would eat lots of resources.
Comment 66 Greg K. 2003-01-10 16:23:54 PST
Is there anyone not on the CC list that might be able to clarify that or advise?
(It's the only aspect of this bug I've ever been interested in.)
Comment 67 Heikki Toivonen (remove -bugzilla when emailing directly) 2003-01-10 16:41:39 PST
I don't think there is a big need for external document support. There are also
the security implications. We would simply not allow a usemap attribute to fetch
a resource from a third party site (same origin policy, if you want to look this
up). Setting document.domain could help a little, but you'd need to either own
the other site or convince the other site owners to do it for you. If you have
the map file on your host, you could simply do server side includes to include
that map file in all the relevant locations (you could fetch remote map files
before doing local includes as well, I guess).
Comment 68 Heikki Toivonen (remove -bugzilla when emailing directly) 2003-01-10 16:59:19 PST
Comment on attachment 111239 [details] [diff] [review]
Potential fix

Clobber build did not help. Can anyone see what is wrong?
Comment 69 Heikki Toivonen (remove -bugzilla when emailing directly) 2003-01-10 19:01:43 PST
Comment on attachment 111239 [details] [diff] [review]
Potential fix

Some more clues... I tried creating a temporary variable to hold the value that
would be passed into htmlDoc->GetImageMap() like this:

const nsAString &usemap = (hash < 0) ? aUsemap : Substring(start, end);

However, this part:

const nsAString &usemap = aUsemap

won't compile (cannot instantiate abstract class). I can't see what's wrong. I
can make that compile by wrapping aUsemap in
Substring(aUsemap,0,aUsemap.Length()) but that seems nuts...
Comment 70 Heikki Toivonen (remove -bugzilla when emailing directly) 2003-01-13 19:21:18 PST
At dbaron's suggestion I casted the return value from |Substring| to |(const
nsAString&)| which makes it compile and run on Windows. However, I am concerned
if this is safe and if it will compile on other platforms (dbaron implied HP
might have problems with it)?
Comment 71 Jim Dunn 2003-01-15 09:37:05 PST
Comment on attachment 111239 [details] [diff] [review]
Potential fix

I was able to compile this on HP (so there compiler was fine with it)
Comment 72 Heikki Toivonen (remove -bugzilla when emailing directly) 2003-01-15 10:07:36 PST
Bleargh! Simple casting doesn't seem to be the solution. On Windows I crash on, calling pure virtual function :(

So, the most effective solution would seem to be to change

+    htmlDoc->GetImageMap(hash < 0 ? aUsemap : Substring(start, end), aMap);


+    if (hash < 0)
+      htmlDoc->GetImageMap(aUsemap, aMap);
+    else
+      htmlDoc->GetImageMap(Substring(start, end), aMap);

and likewise for the XHTML case. Will attach a new patch.
Comment 73 Heikki Toivonen (remove -bugzilla when emailing directly) 2003-01-15 10:31:40 PST
Created attachment 111631 [details] [diff] [review]
Fix v2
Comment 74 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-01-17 11:20:24 PST
Comment on attachment 111631 [details] [diff] [review]
Fix v2

Comment 75 Heikki Toivonen (remove -bugzilla when emailing directly) 2003-01-18 17:09:17 PST
Comment 76 Roland Mainz 2003-01-19 23:06:57 PST
This patch broke the StaticBuild on Solaris/Forte (fails to link both
"mozilla-bin" and "phoenix-bin"):
-- snip --
/opt/SUNWspro/bin/CC -o phoenix-bin -I/usr/openwin/include -xbuiltin=%all -mt 
-DNDEBUG -DTRIMMED -xO2 -xspace  nsBrowserApp.o nsSta
ticComponents.o -xildoff -zlazyload -zcombreloc    -L../../dist/bin
-L../../dist/lib  -lsocket -ldl -lm  -L../../dist/lib/components
 -lxpconnect -luconv -lucvmath -li18n -lctl -lnecko -lnecko2 -luriloader -lpref
-loji -lcaps -lchrome -lrdf -lhtmlpars -lgfx_gtk -lg
fxxprint -limgmng -limglib2 -lgkplugin -ljsurl -ljsdom -lgkview -lwidget_gtk
-lxremote_client -lgklayout -lmork -ldocshell -lprofile
 -lnsprefm -lembedcomponents -lwebbrwsr -leditor -ltxmgr -laccessibility
-lnsappshell -lfileview -lmozfind -lregviewer -lshistory -l
xremoteservice -lappcomps -ltoolkitcomps -lcookie -lwallet -lwalletviewers
-lxmlextras -lautoconfig -ltransformiix -luniversalcharde
t -ltypeaheadfind -lpipboot -lpipnss -lpippki -lbrowsercomps -ljsloader_s
-lunicharutil_s -lucharucomp_s -lucvutil_s -lplatlocale_s 
-lstrres_s -llwbrk_s -lchardet_s -lmozpango -lmozpango-thaix -lmozpango-dvngx
-ljsj -lgtksuperwin -lgtkxtbin -lnkcache_s -lgfxshared
_s -lxlibrgb -lgkgfx -limglib2_s -limgxbm_s -ltxtsvc_s -lmozbrwsr_s -lxulapp_s
../../dist/lib/libxulapp_s.a -L../../dist/bin -lmozjs
 -L../../dist/bin -lxpcom 
-lplds4 -lplc4 -lnspr4
 -lpthread -ldl -lrt  -L/usr/local/lib -L/usr/openwin/lib -R/usr/openwin/lib
-lgtk -lgdk -lgmodule -lglib -ldl -lXext -lX11 -lsocket
 -lnsl -lm  -L../../dist/lib/components -L../../dist/lib -lmozpng
-L../../dist/lib -lmozmng -L../../dist/lib -lmozjpeg -L../../dist/
lib -lmozz  -L/usr/openwin/lib -R/usr/openwin/lib -lXp -lXext -lX11 
-L../../dist/bin -L../../dist/lib ../../dist/lib/libcrmf.a -lsm
ime3 -lssl3 -lnss3 -lsoftokn3   -L/usr/openwin/lib -R/usr/openwin/lib -lXt   
Undefined                       first referenced
 symbol                             in file
unsigned Distance(const nsReadingIterator<unsigned short>&,const
nsReadingIterator<unsigned short>&) ../../dist/lib/components/libgk
ld: fatal: Symbol referencing errors. No output written to phoenix-bin
-- snip --
Comment 77 Roland Mainz 2003-01-19 23:08:17 PST
Created attachment 112035 [details] [diff] [review]
Patch for 2003-01-19-18-trunk to fix the StaticBuild
Comment 78 Roland Mainz 2003-01-19 23:11:42 PST
Comment on attachment 112035 [details] [diff] [review]
Patch for 2003-01-19-18-trunk to fix the StaticBuild

Requesting r=/sr=/a=/moa=/goat= and checkin... :)
Comment 79 Dan Mosedale (:dmose) 2003-01-20 03:02:12 PST
Comment on attachment 112035 [details] [diff] [review]
Patch for 2003-01-19-18-trunk to fix the StaticBuild

Comment 80 hacker formerly known as 2003-01-20 03:58:58 PST
Attachment 112035 [details] [diff] has been checked in.
Comment 81 Greg K. 2003-03-24 18:22:50 PST
See also follow-on bug 189643.

Note You need to log in before you can comment on or make changes to this bug.