Treat USEMAP attribute values as URI data rather than CDATA or IDREF

RESOLVED FIXED in mozilla1.3beta

Status

()

Core
Layout
P3
normal
RESOLVED FIXED
19 years ago
13 years ago

People

(Reporter: Doug Sheppard, Assigned: Heikki Toivonen (remove -bugzilla when emailing directly))

Tracking

({compat, testcase, topembed+})

Trunk
mozilla1.3beta
compat, testcase, topembed+
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fixinhand][bae:20011119][TESTCASE][HTML4-13.6], URL)

Attachments

(5 attachments, 1 obsolete attachment)

(Reporter)

Description

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

Updated

19 years ago
Status: NEW → ASSIGNED

Updated

19 years ago
Severity: normal → enhancement
Priority: P2 → P3

Comment 1

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

Comment 2

19 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

Updated

19 years ago
Priority: P3 → P5

Updated

19 years ago
Summary: USEMAP cannot find map on separate page → {feature} USEMAP cannot find map on separate page
(Reporter)

Updated

18 years ago
(Reporter)

Comment 3

18 years ago
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.

Updated

18 years ago
Severity: enhancement → normal

Comment 5

18 years ago
Miscategorized as enhancement. It's a bug. Severity changed back to Normal.
(Reporter)

Updated

18 years ago
Whiteboard: [MAKINGTEST]
(Reporter)

Comment 6

18 years ago
Created attachment 744 [details]
HTML fragment with image referencing USEMAP from another document
(Reporter)

Comment 7

18 years ago
Created attachment 745 [details]
Contains imagemap for test case
(Reporter)

Comment 8

18 years ago
Created attachment 746 [details]
100x100 GIF image, in case you don't have one handy for testcase
(Reporter)

Comment 9

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

Updated

18 years ago
Severity: normal → enhancement

Comment 10

18 years ago
Umm, reverted back to an ehancement request. Since I use the bug prioritize *my*
bugs, stop messing it with please.
Blocks: 7954
(Reporter)

Updated

18 years ago
Whiteboard: [MAKINGTEST] → [TESTCASE]
(Reporter)

Comment 11

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

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WONTFIX

Comment 12

18 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.
Severity: normal → enhancement
Status: RESOLVED → REOPENED
Component: DOM Level 1 → Layout
OS: Windows 95 → All
Priority: P3 → P5
Hardware: PC → All
Whiteboard: [TESTCASE] → [TESTCASE] Current implementation is spec-compliant, but could be enhanced later.
Target Milestone: M17
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: WONTFIX → LATER
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

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

Comment 15

18 years ago
mine now
Assignee: kipp → buster
Status: RESOLVED → NEW

Comment 16

18 years ago
resetting later resolution accidentally removed
Status: NEW → RESOLVED
Last Resolved: 18 years ago18 years ago
Reopening and moving to Future...
Summary: {feature} USEMAP cannot find map on separate page → USEMAP cannot find map on separate page
Target Milestone: --- → Future
Erm, _really_ reopening...
Status: RESOLVED → REOPENED
Resolution: LATER → ---

Updated

17 years ago
Status: REOPENED → ASSIGNED
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.
Keywords: testcase

Comment 20

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

Comment 21

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

Comment 22

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

Comment 23

17 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.
iirc, comments in the DTD are considered non-normative
See also bug 51339.

Comment 26

16 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.
Severity: enhancement → normal
Whiteboard: [TESTCASE] Current implementation is spec-compliant, but could be enhanced later. → [TESTCASE]
*** Bug 102851 has been marked as a duplicate of this bug. ***

Comment 28

16 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.
Assignee: buster → attinasi
Status: ASSIGNED → NEW

Comment 29

16 years ago
accepting since buster is not on the project anymore.
Status: NEW → ASSIGNED

Comment 30

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

Comment 31

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

Comment 32

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

Updated

16 years ago
Keywords: html4

Updated

16 years ago

Comment 33

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

Comment 34

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

Updated

16 years ago
Depends on: 87050

Comment 35

16 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.
Priority: P5 → P3
Target Milestone: Future → mozilla1.0

Comment 36

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

Comment 37

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

Updated

16 years ago
No longer depends on: 87050

Updated

16 years ago
Blocks: 87050

Comment 38

16 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.)
Keywords: html4
Whiteboard: [TESTCASE] → [TESTCASE] [This is a fault in Mozilla's HTML 3.2 compliance]
Replacing html4 keyword. Whether or not it was in HTML 3.2 is irrelevant to the
fact that it blocks HTML 4.01.
Keywords: html4

Updated

16 years ago
Summary: USEMAP cannot find map on separate page → Treat USEMAP attribute values as URI data type rather than CNAME

Updated

16 years ago
Summary: Treat USEMAP attribute values as URI data type rather than CNAME → Treat USEMAP attribute values as URI data type rather than CDATA
*** 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. ***

Updated

16 years ago
Keywords: html4

Comment 43

16 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
Whiteboard: [TESTCASE] [This is a fault in Mozilla's HTML 3.2 compliance] → [bae:20011119][TESTCASE]

Updated

16 years ago
QA Contact: gerardok → petersen

Updated

16 years ago
Target Milestone: mozilla1.0 → mozilla1.2

Updated

16 years ago
Keywords: mozilla1.0

Comment 44

16 years ago
*** 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.

Comment 46

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

Comment 47

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

Comment 48

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

Comment 49

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

Comment 50

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

Comment 51

16 years ago
*** Bug 131543 has been marked as a duplicate of this bug. ***
Whiteboard: [bae:20011119][TESTCASE] → [bae:20011119][TESTCASE][HTML4-13.6]

Comment 52

16 years ago
not critical for 1.0
Keywords: mozilla1.0 → mozilla1.0-
Apparently the HTML WG now plans to release an erratum returning the usemap
attribute to URI, rather than IDREF.

Comment 54

15 years ago
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. ***

Comment 58

15 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?
Keywords: compat, nsbeta1, topembed

Comment 59

15 years ago
Discussed in edt.  Plussing and reassinging to saari to determine if we can get
in for 1.3
Keywords: topembed → topembed+

Comment 60

15 years ago
==>saari
Assignee: attinasi → saari
Status: ASSIGNED → NEW

Comment 61

15 years ago
this should go to content folks
->heikki
Assignee: saari → heikki
I can try to take this on...
Status: NEW → ASSIGNED
Target Milestone: mozilla1.2alpha → mozilla1.3beta

Updated

15 years ago
Summary: Treat USEMAP attribute values as URI data type rather than CDATA → Treat USEMAP attribute values as URI data rather than CDATA or IDREF
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
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...

Comment 64

15 years ago
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.

Comment 66

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

15 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)
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.
Created attachment 111631 [details] [diff] [review]
Fix v2
Attachment #111239 - Attachment is obsolete: true
Attachment #111631 - Flags: superreview?(roc+moz)
Attachment #111631 - Flags: review?(dbaron)
Whiteboard: [bae:20011119][TESTCASE][HTML4-13.6] → [fixinhand][bae:20011119][TESTCASE][HTML4-13.6]
Comment on attachment 111631 [details] [diff] [review]
Fix v2

r+sr=roc+moz
Attachment #111631 - Flags: superreview?(roc+moz)
Attachment #111631 - Flags: superreview+
Attachment #111631 - Flags: review?(dbaron)
Attachment #111631 - Flags: review+
Fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago15 years ago
Resolution: --- → FIXED

Updated

15 years ago
Blocks: 189643

Updated

15 years ago
No longer blocks: 87050

Comment 76

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

Comment 77

15 years ago
Created attachment 112035 [details] [diff] [review]
Patch for 2003-01-19-18-trunk to fix the StaticBuild

Comment 78

15 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... :)
Attachment #112035 - Flags: superreview?(roc+moz)
Attachment #112035 - Flags: review?(roc+moz)

Updated

15 years ago
Attachment #112035 - Flags: superreview?(roc+moz)
Attachment #112035 - Flags: superreview?(dmose)
Attachment #112035 - Flags: review?(seawood)
Attachment #112035 - Flags: review?(roc+moz)
Attachment #112035 - Flags: review?(seawood) → review+
Comment on attachment 112035 [details] [diff] [review]
Patch for 2003-01-19-18-trunk to fix the StaticBuild

sr=dmose
Attachment #112035 - Flags: superreview?(dmose) → superreview+
Attachment 112035 [details] [diff] has been checked in.

Comment 81

15 years ago
See also follow-on bug 189643.
You need to log in before you can comment on or make changes to this bug.