87050 - client side imagemaps fails if space in map name

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[E.deWilde]

If there is a space in the name of the imagemap the name of the url is not
displayed when moving the mouse over the active area of the map. Also the size
and shape of the active area are incorrect. Clicking on the active area doesn't
produce any result. Expected result is the opening of the specified url.
Things work right when there is no space in the name of the map.

Comment 1

[Tom Mraz]

Attachment: Testcase

Comment 2

[Tom Mraz]

I can confirm this on Linux -> not platform specific.
I created a testcase because the original URL is fixed.

Comment 3

[Bob Clary [:bc] (inactive)]

giving to intl team

Comment 4

[Jacob Kjome]

Fails in IE5.5, Opera 5.11, and Netscape 4.77 as well.

Jake

Comment 5

[johan]

This bug is causing me serious problems. It worked in 0.8.1 and doesn't work in
0.9.1.
I created a testcase that works with netscape 4.x and IE, and it doesn't
work in 
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.1+) Gecko/20010622

The testcase 39482 is buggy. usemap="#intromap" should be usemap="#intro map".
That's why it doesn't work on any browsers.


This smells like a real browser bug, not evangelism.

Comment 6

[Chris Meyer]

I see this frequently. Checkout the site <A
HREF="http://www.sfdesigncenter.com">www.sfdesigncenter.com</A>. Why is this
marked evangelism? Does this fly in the face of some w3c spec?

Comment 7

[johan]

Eh, can someone please tell me what's european about a space?
And still evangelism.... Why? Could someone tell me what specs we are vioalting
and I will try to fix the pages I have control over. 

Comment 8

[Katsuhiko Momoi]

johan is right. This is not an evangelism bug.

(By the way, the reason for classifying as European 
 is due to who this should be assigned to in case 
 it is an evangelism bug. .nl sites are usually 
 in Dutch and that is why this bug was put in the
 European component.)

In any case, this should be classified as bug.
Using a space character for an usemap name
should not violate any W3C spec though it probably
isn't a good idea.

But this is very much like using an anchor name like
"#test case" and expect to find the internal target
within a document. In fact Mozilla does find such
an internal target for anchor names.

The usemape name with a space in it should be 
processed just like an anchor name with a 
space in it as long such names are clearly
surrounded by parentheses. The test
case above works OK with IE5.x and Comm 4.x when
you correct the name to "#intro map". It
fails only with current Mozilla builds.

I'll upload a modified test case of the
above.

Comment 9

[Katsuhiko Momoi]

Attachment: A corrected test case -- now contains "#intro map" as the usemap name, which matches the map name.

Comment 10

[Katsuhiko Momoi]

View the test case with IE5, Comm 4.x and
current Mozilla. Only Mozilla fails to have
an activated link.
There was a similar bug earlier this week.
That one went to dougt. Sending this
over to valeski and CC'ing dougt.
Changing the product and component.

Comment 11

[Katsuhiko Momoi]

CC'ing neeti.

Comment 12

[Philipp Ebneter]

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

Comment 13

[David Einstein]

OK the problem here is this line in nsImageMapUtils.cpp (Line 49)

  // Strip out whitespace in the name for navigator compatibility
  // XXX NAV QUIRK
  usemap.StripWhitespace();
Unfortunately the whitespace is not stripped in the map name so that if there is
a space no match occurs.  There are a few ways of addressing this.

1) Remove the offending line.  It's a stupid quirk.
2) Change nsHTMLDocument::GetImageMap to try to match first with spaces then
without. Just what Mozilla needs, stupid busy work.
3) Strip the spaces in the map name and pray that it doesnt break too many pages.

Comment 14

[David Einstein]

Attachment: Patch 1 part a

Comment 15

[David Einstein]

Attachment: Patch 1 part b

Comment 16

[David Einstein]

Attachment: Quirk testcase

Comment 17

[David Einstein]

Patch 1 part a is sufficient to fix the bug as reported.  Part b is to restore what
I believe is the intended quirk behavior.  The testcase tests the reintroduction
of the quirky behavior.

Comment 18

[David Einstein]

A bit of digging in the specs leads me to believe that the map names should be
case sensitive -- they are URI's after all.  The HTML 3.2 spec explicitly states
that, the 4.01 spec only mentions that it's a URI.  Unfortunately I have no idea
what will break if we do a case sensitive compare. 

Comment 19

[Jacek Piskozub]

David: No, you are wrong. The MAP NAME attribute is case insensitive in HTML
4.01. See the letters CI in its definition on
http://www.w3.org/TR/html4/struct/objects.html#edef-MAP

Comment 20

[Jacek Piskozub]

Anyway, it should be Parser, not Networking. Moving.

Comment 21

[Jacek Piskozub]

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

Comment 22

[Jacek Piskozub]

The dup bug 95355 has this very problem (spaces in map name) plus the fact that
the URL of type file.html#MapName in IMG USEMAP does not work when file.html is
the actually parsed file (link to itself). Should I file a separate bug on this?

Comment 23

[Niels Aufbau]

Jacek - that would be covered by bug 74867 if it wasn't marked as an evangelism bug.

Comment 24

[Alfonso Martinez]

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

Comment 25

[timeless]

i was pretty sure that "#foo bar" wasn't valid (and as such would be evang 
fodder). i'll hunt that down later.

Comment 26

[Susie Wyshak]

FYI another example of a map that doesn't work and has a space in its name. I
will evangelize it but thought "just for the record" it might indicate that the
product should be more forgiving to hapless developers.

http://www.boeing.com/defense-space/space/

Comment 27

[Greg K.]

The USEMAP attribute and the NAME attribute have contained data types different
from one another since their inception in HTML 3.2. USEMAP contains CDATA, and
NAME contains a %URL (%URI in more recent HTML versions).

So, the space character in the USEMAP attribute value must be encoded, but the
space character in the NAME attribute value should not be. Mozilla must parse
the  USEMAP %URI, decoding characters as appropriate before referencing the
named MAP.

For example,

<map name="the map"><area/></map>
<img src="foo.gif" usemap="#the%20map"/>

In the example, the img refers to the map, and Mozilla must function as such.

Comment 28

[Greg K.]

Of course, this bug is but a small part of treating the USEMAP attribute like a
proper %URI in general, which is really what bug 1882 is all about. Marking this
bug as a blocker of that bug.

Comment 29

[Greg K.]

Comment on attachment 39482 [details]
Testcase

Obsolete because USEMAP does not reference MAP NAME.

Comment 30

[Greg K.]

Comment on attachment 45509 [details]
A corrected test case -- now contains "#intro map" as the usemap name, which matches the map name.

Invalid because space character in USEMAP value must be encoded as %20.

Comment 31

[Greg K.]

Comment on attachment 47511 [details]
Quirk testcase

Invalid because USEMAP value does not validly address NAMEd MAP.

Comment 32

[Greg K.]

It should be noted that, in HTML 4.0 and 4.0.1 (as well as XHTML 1.0), space
characters are not allowed in MAP NAME or ID attributes (e.g.,
[http://www.w3.org/TR/html4/types.html#type-cdata]).

Thus, support for them should not be implemented in either quirks or strict
mode. Quirks mode is only intended to compensate for widely-implemented coding
incompatibilies with the DTDs, not one-off problems. This does not qualify.

Note that this matter is less clear in HTML 3.2. So, unless it can be shown
otherwise, only in the instance of strict HTML 3.2 conformance may space
characters be tolerated. Be aware that the USEMAP URI value must still encode
space characters as %20.
Will shortly attach a purely HTML 3.2 testcase.

Comment 33

[Greg K.]

Comment on attachment 47511 [details]
Quirk testcase

IMG USEMAP attribute does not properly reference MAP NAME value.

Comment 34

[Greg K.]

Attachment: Purely HTML 3.2 testcase, as that is the only DTD that may allow spaces in MAP NAME attribute values.

Comment 35

[Niels Aufbau]

Greg, are you saying that Mozilla should only support spaces in usemap when
there's an HTML 3.2 doctype at the top of the page?  Good luck convincing
authors of old content to add the doctype tag...

Comment 36

[Greg K.]

Niels, I would say HTML 3.2, or DOCTYPE-less. That doesn't exactly match Quirks
mode, though, since that does all sorts of nonsense with HTML 4.0 Transitional.
Otherwise, the specs are perfectly clear...space characters are specifically
disallowed in NAME and ID values, so there's never any legal opportunity to
craft USEMAP values that refer to them.

In any case, unencoded space characters are never be allowed in USEMAP values.
They must be encoded. If they occur in someone's web page, that's a matter for
Evangelism.

Comment 37

[Jacek Piskozub]

Should we also evangelize W3C as their HTML Validator finds no fault with spaces
in  the USEMAP URI within a HTML 4.01 Transitional document?

Isn't it a case of us trying to be more holy then the Pope?

Comment 38

[Greg K.]

Jacek, you're right. I veered off a bit and started thinking in terms of how
people should code rather than how Mozilla should behave.

So, while it is true that HTML specifically doesn't allow spaces in NAMEs and
IDs, Mozilla should be able to handle them since, in fact, Mozilla's HTML parser
is not validating.

The part about encoding spaces is still true. I've misplaced the reference at
the moment, but it's in the HTML DTDs as comments, which aren't recognized by
the parser used by the W3C Validator. (Note that BBEdit's syntax checker does
include DTD comments.)

Comment 39

[Greg K.]

Ah, yes; the URI specification, RFC 2396
([http://www.ietf.org/rfc/rfc2396.txt]),  Ch. 2.4.3, is on point with respect to
space character encoding.

Comment 40

[Judson Valeski]

no idea here. pavlov?

Comment 41

[Greg K.]

Actually, this bug should depend on bug 1882, rather than block it. This bug
will be solved when, to fix bug 1882, USEMAPs are changed to hold a %URI data
type rather than simply CDATA.

Comment 42

[Stuart Parmenter]

don't know anything about image maps

Comment 43

[harishd]

Attachment: [ MAP name="intromap" ]

Works neither in IE nor in N6.x

Comment 44

[harishd]

Attachment: Testcase 2 [ MAP name="intromap" ] *NO BUG HERE*

Works on N6.x and IE.

Comment 45

[harishd]

Attachment: Testcase3 [ MAP name="intro map" usemap="#intromap" usemap="#intromap"

Please ignore my first attachment.

Comment 46

[harishd]

Marking INVALID.

Comment 47

[timeless]

vrfy invalid, the site seems to have fixed itself

Comment 48

[johan]

Invalid....
First this bug was evangelism, then european evangelism then a bug and now
invalidated without comment.
Fact is: It still doesn't work.
Fact is: It used to work.
Fact is: It works on IE4-6, Netscape4, Opera 5

Sorry for nagging but I'd really would like to know why this bug is invalid.

Comment 49

[harishd]

johan: Please refer to my comment ( 2001-11-08 13:03 ) " Works neither in IE nor
in N6.x ".

Comment 50

[johan]

Testcase 3 is "Yet another buggy testcase". Please use the space consistently in
the testcase. That is: usemap="#intro map", not usemap="#intromap"

Comment 51

[Henrik Rundqvist]

This is getting sad.

The testcases presented are buggy. It got pointed out ages ago the first time.
From the code:

<img ...... usemap="#intromap">
<map name="intro map">

Of course it doesn't work.

BUT you are right about one thing. Netscape 6.x can't handle imagemaps with a
space in the name. Since it's based on Mozilla code ........

MS Internet Explorer however does indeed work with imagemaps with spaces in the
name!! And that includes all versions I have tested.

ALSO it works in Netscape 4.x and Opera.

And that is the whole point! Mozilla and Netscape 6.x is the ones NOT handling
this correctly but the rest of the pack is!

This is a bug.

It's the second time a BUGGY testcase is posted here.

This is getting somewhat frustrating. :)

Comment 52

[Susie Wyshak]

I am reopening this while the discussion continues. 
FYI this site's 2-worded image map works in IE:
http://www.boeing.com/defense-space/space/

Comment 53

[Susie Wyshak]

Another example: http://www.text-trieve.com/dotrspa/

Comment 54

[harishd]

Attachment: Yet another testcase

yikes!...I thought I tested this bug throughly..apparently not :(. Anyway..I do
see the bug but I don't think it's parser related since I do see the attribute 

"space map" [ checkout the content model - on the URL bar type javascript:
alert(document.body.innerHTML) ]. I'm not sure where this bug should go but my
first guess is layout.

Comment 55

[harishd]

--> layout

Comment 56

[Greg K.]

I do still think this is Quirks-only, since HTML technically doesn't allow space
characters in ID and NAME CDATA values.

So, any instances of this problem in reference to Strict mode would be Evangelism.

Comment 57

[David Einstein]

A few comments
1) this bug belongs to whoever owns /mozilla/content/shared/src/nsImageMapUtils.cpp

The problem is the lines that read

  // Strip out whitespace in the name for navigator compatibility
  // XXX NAV QUIRK
  usemap.StripWhitespace();

and do exactly what they claim (though the motivation seems off.)

2) To insist that any characters other than ";","/", "?", ":", "@", "=", "#" and
"&", that can have special meaning in a URI or obviously "\"", which would
terminate the attribute, be escaped in the usmap, or any other, attribute seems
insanely pedantic. Mozilla should be able to escape these characters itself.
Mozilla does so with the <a href="#foo bar"> tag quite nicely.  Characters like
space are unsafe because they can begarbled in transit.  All of which is quite
moot until we implement URI's in usmap attributes, and that does not seem to be
a feature the world is claboring for.

Comment 58

[Marc Attinasi]

Sounds similar to bug 79738, where we removed a quirk that stripped the
whitespace our of the NAME attribute of the MAP element.

Anyway, I'll fix this.

Comment 59

[Marc Attinasi]

Comment on attachment 57088 [details]
Testcase3 [ MAP name="intro map"
usemap="#intromap"
usemap="#intromap"

This testcase is wrong: usemap has space but map name does not.
usemap="#intromap"
name="intro map"

Comment 60

[Marc Attinasi]

Attachment: Small testcase that has space in image usemap and map name attribute values

Comment 61

[Marc Attinasi]

Attachment: PATCH: just like previous patch (Patch 1 part a) but with a big ol' comment to explain

Comment 62

[Niels Aufbau]

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

Comment 63

[Marc Attinasi]

Looks like TOPEMBED was removed. Since the patch is really David's, I'll sr it.
We need some other reviews though.

Comment 64

[Marc Attinasi]

Comment on attachment 57980 [details] [diff] [review]
PATCH: just like previous patch (Patch 1 part a) but with a big ol' comment to explain

sr=attinasi | patch is David Einstein, I just added the comment.

Comment 65

[Kevin McCluskey (gone)]

Comment on attachment 57980 [details] [diff] [review]
PATCH: just like previous patch (Patch 1 part a) but with a big ol' comment to explain

r=[e-mail]

Comment 66

[Marc Attinasi]

Checked in patch:

Checking in nsImageMapUtils.cpp;
/cvsroot/mozilla/content/shared/src/nsImageMapUtils.cpp,v  <--  nsImageMapUtils.cpp
new revision: 3.3; previous revision: 3.2

Comment 67

[Susie Wyshak]

Another example problem site; we will evangelize it:
http://www.rca.com/content/viewdetail/1,,EI700155,00.html

(fyi boeing now uses Flash so problem no longer exists)
Added nsbeta1.

Comment 68

[Chris Petersen]

Verified (2002-04-22-03).

Comment 69

[Greg K.]

Removing dependency on bug 1882 since the two bugs were fixed independently of
each other.