Doug Sheppard Reporter
	Description • 26 years ago

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.

	kipp
	Comment 1 • 26 years ago

I've marked this as an enhancement request since its not yet supported in other
browsers. We *should* do it, its just lower priority.

	Paul MacQuiddy
	Comment 2 • 26 years ago

per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

	Doug Sheppard Reporter
	Comment 3 • 26 years ago

The original URL has disappeared from the face of the earth, so I've removed it.

	Hixie (not reading bugmail)
	Comment 4 • 26 years ago

Documentation for the USEMAP feature is in the HTML specification:
   http://www.w3.org/TR/REC-html40/struct/objects.html#h-13.6

Note that this feature is required for a 100% HTML4 implementation.

	gerardok
	Comment 5 • 26 years ago

Miscategorized as enhancement. It's a bug. Severity changed back to Normal.

	Doug Sheppard Reporter
	Comment 9 • 25 years ago

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.

	kipp
	Comment 10 • 25 years ago

Umm, reverted back to an ehancement request. Since I use the bug prioritize *my*
bugs, stop messing it with please.

	Doug Sheppard Reporter
	Comment 11 • 25 years ago

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

	kipp
	Comment 12 • 25 years ago

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

I'm marking this wont-fix. Feel free to change it to invalid if you agree with
my spec analysis.

	Hixie (not reading bugmail)
	Comment 13 • 25 years ago

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

	Nicholas Cull
	Comment 14 • 25 years ago

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

	buster
	Comment 15 • 25 years ago

mine now

	buster
	Comment 16 • 25 years ago

resetting later resolution accidentally removed

	Hixie (not reading bugmail)
	Comment 17 • 24 years ago

Reopening and moving to Future...

	Hixie (not reading bugmail)
	Comment 18 • 24 years ago

Erm, _really_ reopening...

	Hixie (not reading bugmail)
	Comment 19 • 24 years ago

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.

	Fabian Guisset
	Comment 20 • 24 years ago

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

	Greg K.
	Comment 21 • 24 years ago

FWIW, I'm pretty sure this feature was present in Mac IE 4.5, though it
apparently went extinct in their 5 product.

	Greg K.
	Comment 22 • 24 years ago

For the hell of it, an easily accessible testcase is available at
"http://greg.tcp.com/mozilla/map/image.html". I always wanted to see this
feature work *somewhere*. :)

	Daniel J. Peng
	Comment 23 • 24 years ago

There is more to this bug, and at http://www.frhsd.com/index.htm , 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 http://www.frhsd.com/index.htm as
http://www.frhsd.com/ .  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 http://www.frhsd.com/ and http://www.frhsd.com/index.htm . I
suspect that it is breaking standards, though.  If accessing
http://www.frhsd.com/ 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
http://www.w3.org/TR/REC-html40/strict.dtd 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.

	Hixie (not reading bugmail)
	Comment 24 • 24 years ago

iirc, comments in the DTD are considered non-normative

	Hixie (not reading bugmail)
	Comment 25 • 24 years ago

See also bug 51339.

	Braden
	Comment 26 • 23 years ago

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.

	Christopher Hoess (gone)
	Comment 27 • 23 years ago

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

	Marc Attinasi
	Comment 28 • 23 years ago

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.

	Marc Attinasi
	Comment 29 • 23 years ago

accepting since buster is not on the project anymore.

	Greg K.
	Comment 30 • 23 years ago

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 "#"
character.

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 [http://www.w3.org/TR/html4/struct/objects.html#adef-usemap].)

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.

	Greg K.
	Comment 31 • 23 years ago

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

	Marc Attinasi
	Comment 32 • 23 years ago

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.

	Susie Wyshak
	Comment 33 • 23 years ago

Any insight into why the "space map" image map doesn't work on this page? I 
thought it might be related to this bug.
http://www.boeing.com/defense-space/space/

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

Works ok in Netscape 4.7 & IE. 

	Susie Wyshak
	Comment 34 • 23 years ago

The answer is as I suspected and is in
http://bugzilla.mozilla.org/show_bug.cgi?id=87050
so please disregard. Thanks.

	Marc Attinasi
	Comment 35 • 23 years ago

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.

	Greg K.
	Comment 36 • 23 years ago

I have updated my testcases at [http://greg.tcp.com/mozilla/map/] with both
Quirks (HTML 4.0 Transitional) and Strict (XHTML 1.0 Strict) versions. Any patch
must apply to both.

	Greg K.
	Comment 37 • 23 years ago

Also, it may be wise to include people associated with such technologies as DOM,
XLink, XPath, and XPointer for their input on this.

	Greg K.
	Comment 38 • 23 years ago

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

	Christopher Hoess (gone)
	Comment 39 • 23 years ago

Replacing html4 keyword. Whether or not it was in HTML 3.2 is irrelevant to the
fact that it blocks HTML 4.01.

	Christopher Hoess (gone)
	Comment 40 • 23 years ago

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

	Christopher Hoess (gone)
	Comment 41 • 23 years ago

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

	Boris Zbarsky [:bzbarsky]
	Comment 42 • 23 years ago

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

	rubydoo123
	Comment 43 • 23 years ago

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

	Koike Kazuhiko
	Comment 44 • 23 years ago

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

	Christopher Hoess (gone)
	Comment 45 • 23 years ago

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.

	Greg K.
	Comment 46 • 23 years ago

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.

	Christian Schmidt
	Comment 47 • 23 years ago

Quote from 
http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/dtd_module_defs.html
#a_module_Client-side_Image_Map

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

	Greg K.
	Comment 48 • 23 years ago

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

	timeless
	Comment 49 • 23 years ago

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

	Greg K.
	Comment 50 • 23 years ago

That notwithstanding, this still will need to be done for HTML 3.2 through HTML
4.0.1 and XHTML 1.0.

	Jacek Piskozub
	Comment 51 • 23 years ago

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

	Asa Dotzler [:asa]
	Comment 52 • 23 years ago

not critical for 1.0

	Christopher Hoess (gone)
	Comment 53 • 23 years ago

Apparently the HTML WG now plans to release an erratum returning the usemap
attribute to URI, rather than IDREF.

	Greg K.
	Comment 54 • 23 years ago

That's good news; thanks, Christopher. Do you have a URL or other reference to
that news?

	Christopher Hoess (gone)
	Comment 55 • 22 years ago

http://lists.w3.org/Archives/Public/www-html/2002Apr/0013.html

	Boris Zbarsky [:bzbarsky]
	Comment 56 • 22 years ago

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

	Boris Zbarsky [:bzbarsky]
	Comment 57 • 22 years ago

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

	Bob Clary [:bc] (inactive)
	Comment 58 • 22 years ago

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?

	Michael Buckland
	Comment 59 • 22 years ago

Discussed in edt.  Plussing and reassinging to saari to determine if we can get
in for 1.3

	David Epstein
	Comment 60 • 22 years ago

==>saari

	saari (gone)
	Comment 61 • 22 years ago

this should go to content folks
->heikki

	Heikki Toivonen (remove -bugzilla when emailing directly) Assignee
	Comment 62 • 22 years ago

I can try to take this on...

	Heikki Toivonen (remove -bugzilla when emailing directly) Assignee
	Comment 63 • 22 years ago

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

I put testcases up at http://green.mcom.com/heikki/1882 (Netscape internal
site)

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

	Greg K.
	Comment 64 • 22 years ago

Will the final version handle external documents as well?

	Heikki Toivonen (remove -bugzilla when emailing directly) Assignee
	Comment 65 • 22 years ago

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.

	Greg K.
	Comment 66 • 22 years ago

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

	Heikki Toivonen (remove -bugzilla when emailing directly) Assignee
	Comment 67 • 22 years ago

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

	Heikki Toivonen (remove -bugzilla when emailing directly) Assignee
	Comment 68 • 22 years ago

Comment on attachment 111239 [details] [diff] [review]
Potential fix

Clobber build did not help. Can anyone see what is wrong?

	Heikki Toivonen (remove -bugzilla when emailing directly) Assignee
	Comment 69 • 22 years ago

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

	Heikki Toivonen (remove -bugzilla when emailing directly) Assignee
	Comment 70 • 22 years ago

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

	Jim Dunn
	Comment 71 • 22 years ago

Comment on attachment 111239 [details] [diff] [review]
Potential fix

I was able to compile this on HP (so there compiler was fine with it)

	Heikki Toivonen (remove -bugzilla when emailing directly) Assignee
	Comment 72 • 22 years ago

Bleargh! Simple casting doesn't seem to be the solution. On Windows I crash on
netscape.com, calling pure virtual function :(

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

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

into

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

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 74 • 22 years ago

Comment on attachment 111631 [details] [diff] [review]
Fix v2

r+sr=roc+moz

	Heikki Toivonen (remove -bugzilla when emailing directly) Assignee
	Comment 75 • 22 years ago

Fixed.

	Roland Mainz
	Comment 76 • 22 years ago

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 
-L/shared/bigtmp2/mozilla/phoenix/trunk/objdir_static_2003-01-19-18-trunk/dist/lib
-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
layout.a(nsImageMapUtils.o)
ld: fatal: Symbol referencing errors. No output written to phoenix-bin
-- snip --

	Roland Mainz
	Comment 78 • 22 years ago

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

	Dan Mosedale (:dmosedale, :dmose)
	Comment 79 • 22 years ago

Comment on attachment 112035 [details] [diff] [review]
Patch for 2003-01-19-18-trunk to fix the StaticBuild

sr=dmose

	hacker formerly known as seawood@netscape.com
	Comment 80 • 22 years ago

Attachment 112035 [details] [diff] has been checked in.

	Greg K.
	Comment 81 • 22 years ago

See also follow-on bug 189643.