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.

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

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

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

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.

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

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.

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

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

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.

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

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

mine now

resetting later resolution accidentally removed

Reopening and moving to Future...

Erm, _really_ reopening...

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.

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

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

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

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.

iirc, comments in the DTD are considered non-normative

See also bug 51339.

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.

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

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.

accepting since buster is not on the project anymore.

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.

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

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.

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.

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

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.

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.

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

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

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

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

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

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

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

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

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.

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.

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

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

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

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

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

not critical for 1.0

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

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

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

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

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

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?

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

==>saari

this should go to content folks ->heikki

I can try to take this on...

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

Will the final version handle external documents as well?

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.

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

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 on attachment 111239 [details] [diff] [review] Potential fix Clobber build did not help. Can anyone see what is wrong?

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

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 on attachment 111239 [details] [diff] [review] Potential fix I was able to compile this on HP (so there compiler was fine with it)

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.

Comment on attachment 111631 [details] [diff] [review] Fix v2 r+sr=roc+moz

Fixed.

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

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 on attachment 112035 [details] [diff] [review] Patch for 2003-01-19-18-trunk to fix the StaticBuild sr=dmose

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

See also follow-on bug 189643.