client side imagemaps fails if space in map name

VERIFIED FIXED in mozilla0.9.7

Status

()

Core
Layout
VERIFIED FIXED
17 years ago
16 years ago

People

(Reporter: E.deWilde, Assigned: Marc Attinasi)

Tracking

Trunk
mozilla0.9.7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(6 attachments, 6 obsolete attachments)

(Reporter)

Description

17 years ago
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

17 years ago
Created attachment 39482 [details]
Testcase

Comment 2

17 years ago
I can confirm this on Linux -> not platform specific.
I created a testcase because the original URL is fixed.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows NT → All
Hardware: PC → All

Comment 3

17 years ago
giving to intl team
Assignee: bclary → nitot
QA Contact: zach → momoi

Comment 4

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

Jake

Comment 5

17 years ago
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

17 years ago
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?

Updated

17 years ago
Component: Evangelism → European
Product: Browser → Tech Evangelism
Version: other → unspecified

Comment 7

17 years ago
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

17 years ago
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

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

Updated

17 years ago
Assignee: nitot → valeski
Component: European → Networking
Product: Tech Evangelism → Browser
Version: unspecified → other

Comment 10

17 years ago
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

17 years ago
CC'ing neeti.

Comment 12

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

Comment 13

17 years ago
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

17 years ago
Created attachment 47507 [details] [diff] [review]
Patch 1 part a

Comment 15

17 years ago
Created attachment 47509 [details] [diff] [review]
Patch 1 part b

Comment 16

17 years ago
Created attachment 47511 [details]
Quirk testcase

Comment 17

17 years ago
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.
Keywords: patch

Comment 18

17 years ago
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

17 years ago
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

17 years ago
Anyway, it should be Parser, not Networking. Moving.
Component: Networking → Parser

Comment 21

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

Comment 22

17 years ago
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

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

Comment 24

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

Comment 25

17 years ago
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

17 years ago
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

17 years ago
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

17 years ago
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.
Blocks: 1882

Comment 29

17 years ago
Comment on attachment 39482 [details]
Testcase

Obsolete because USEMAP does not reference MAP NAME.
Attachment #39482 - Attachment is obsolete: true

Comment 30

17 years ago
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.
Attachment #45509 - Attachment is obsolete: true

Comment 31

17 years ago
Comment on attachment 47511 [details]
Quirk testcase

Invalid because USEMAP value does not validly address NAMEd MAP.

Comment 32

17 years ago
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

17 years ago
Comment on attachment 47511 [details]
Quirk testcase

IMG USEMAP attribute does not properly reference MAP NAME value.
Attachment #47511 - Attachment is obsolete: true

Comment 34

17 years ago
Created attachment 53198 [details]
Purely HTML 3.2 testcase, as that is the only DTD that may allow spaces in MAP NAME attribute values.

Comment 35

17 years ago
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

17 years ago
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

17 years ago
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

17 years ago
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

17 years ago
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

17 years ago
no idea here. pavlov?
Assignee: valeski → pavlov

Comment 41

17 years ago
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.
No longer blocks: 1882

Updated

17 years ago
Depends on: 1882

Comment 42

17 years ago
don't know anything about image maps
Assignee: pavlov → harishd
QA Contact: momoi → moied

Comment 43

17 years ago
Created attachment 57084 [details]
[ MAP name="intromap" ]

Works neither in IE nor in N6.x

Comment 44

17 years ago
Created attachment 57086 [details]
Testcase 2 [ MAP name="intromap" ]
*NO BUG HERE*

Works on N6.x and IE.

Comment 45

17 years ago
Created attachment 57088 [details]
Testcase3 [ MAP name="intro map"
usemap="#intromap"
usemap="#intromap"

Please ignore my first attachment.

Comment 46

17 years ago
Marking INVALID.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID

Updated

17 years ago
Attachment #57084 - Attachment description: Testcase [ MAP name="intro map" ] → [ MAP name="intromap" ]
Attachment #57084 - Attachment is obsolete: true

Comment 47

17 years ago
vrfy invalid, the site seems to have fixed itself
Status: RESOLVED → VERIFIED

Comment 48

17 years ago
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

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

Comment 50

17 years ago
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

17 years ago
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

17 years ago
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/
Status: VERIFIED → REOPENED
Keywords: topembed
Resolution: INVALID → ---

Comment 54

17 years ago
Created attachment 57848 [details]
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

17 years ago
--> layout
Assignee: harishd → attinasi
Status: REOPENED → NEW
Component: Parser → Layout
QA Contact: moied → petersen

Comment 56

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

Updated

17 years ago
Target Milestone: --- → mozilla0.9.7

Updated

17 years ago
Keywords: 4xp

Comment 57

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



(Assignee)

Comment 58

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

Status: NEW → ASSIGNED
(Assignee)

Comment 59

17 years ago
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"
Attachment #57088 - Attachment description: Testcase3 [ MAP name="intro map" → Testcase3 [ MAP name="intro map" usemap="#intromap" usemap="#intromap"
Attachment #57088 - Attachment is obsolete: true
(Assignee)

Updated

17 years ago
Attachment #57086 - Attachment description: Testcase 2 [ MAP name="intromap" ] → Testcase 2 [ MAP name="intromap" ] *NO BUG HERE*
(Assignee)

Comment 60

17 years ago
Created attachment 57979 [details]
Small testcase that has space in image usemap and map name attribute values
(Assignee)

Comment 61

17 years ago
Created attachment 57980 [details] [diff] [review]
PATCH: just like previous patch (Patch 1 part a) but with a big ol' comment to explain
Attachment #47507 - Attachment is obsolete: true

Updated

17 years ago
Keywords: topembed

Comment 62

17 years ago
*** Bug 93538 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 63

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

Comment 64

17 years ago
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.
Attachment #57980 - Flags: superreview+
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=kmcclusk@netscape.com
Attachment #57980 - Flags: review+
(Assignee)

Comment 66

17 years ago
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
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 67

17 years ago
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.
Keywords: nsbeta1

Comment 68

16 years ago
Verified (2002-04-22-03).
Status: RESOLVED → VERIFIED

Comment 69

16 years ago
Removing dependency on bug 1882 since the two bugs were fixed independently of
each other.
No longer depends on: 1882
You need to log in before you can comment on or make changes to this bug.