1.05 KB, patch
|Details | Diff | Splinter Review|
Purely HTML 3.2 testcase, as that is the only DTD that may allow spaces in MAP NAME attribute values.
439 bytes, text/html
264 bytes, text/html
1.46 KB, text/html
269 bytes, text/html
739 bytes, patch
Kevin McCluskey (gone): review+
Marc Attinasi: superreview+
|Details | Diff | Splinter Review|
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.
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
giving to intl team
Assignee: bclary → nitot
QA Contact: zach → momoi
Fails in IE5.5, Opera 5.11, and Netscape 4.77 as well. Jake
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.
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?
Component: Evangelism → European
Product: Browser → Tech Evangelism
Version: other → unspecified
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.
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.
Created attachment 45509 [details] A corrected test case -- now contains "#intro map" as the usemap name, which matches the map name.
Assignee: nitot → valeski
Component: European → Networking
Product: Tech Evangelism → Browser
Version: unspecified → other
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.
*** Bug 97282 has been marked as a duplicate of this bug. ***
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.
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.
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.
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
Anyway, it should be Parser, not Networking. Moving.
Component: Networking → Parser
*** Bug 95355 has been marked as a duplicate of this bug. ***
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?
Jacek - that would be covered by bug 74867 if it wasn't marked as an evangelism bug.
*** Bug 103535 has been marked as a duplicate of this bug. ***
i was pretty sure that "#foo bar" wasn't valid (and as such would be evang fodder). i'll hunt that down later.
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/
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.
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 on attachment 39482 [details] Testcase Obsolete because USEMAP does not reference MAP NAME.
Attachment #39482 - Attachment is obsolete: true
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 on attachment 47511 [details] Quirk testcase Invalid because USEMAP value does not validly address NAMEd MAP.
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 on attachment 47511 [details] Quirk testcase IMG USEMAP attribute does not properly reference MAP NAME value.
Attachment #47511 - Attachment is obsolete: true
Created attachment 53198 [details] Purely HTML 3.2 testcase, as that is the only DTD that may allow spaces in MAP NAME attribute values.
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...
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.
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?
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.)
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.
no idea here. pavlov?
Assignee: valeski → pavlov
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
don't know anything about image maps
Assignee: pavlov → harishd
QA Contact: momoi → moied
Created attachment 57086 [details] Testcase 2 [ MAP name="intromap" ] *NO BUG HERE* Works on N6.x and IE.
Created attachment 57088 [details] Testcase3 [ MAP name="intro map" usemap="#intromap" usemap="#intromap" Please ignore my first attachment.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
vrfy invalid, the site seems to have fixed itself
Status: RESOLVED → VERIFIED
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.
johan: Please refer to my comment ( 2001-11-08 13:03 ) " Works neither in IE nor in N6.x ".
Testcase 3 is "Yet another buggy testcase". Please use the space consistently in the testcase. That is: usemap="#intro map", not usemap="#intromap"
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. :)
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
Resolution: INVALID → ---
Another example: http://www.text-trieve.com/dotrspa/
Assignee: harishd → attinasi
Status: REOPENED → NEW
Component: Parser → Layout
QA Contact: moied → petersen
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.
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.
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
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 #57086 - Attachment description: Testcase 2 [ MAP name="intromap" ] → Testcase 2 [ MAP name="intromap" ] *NO BUG HERE*
Created attachment 57979 [details] Small testcase that has space in image usemap and map name attribute values
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
*** Bug 93538 has been marked as a duplicate of this bug. ***
Looks like TOPEMBED was removed. Since the patch is really David's, I'll sr it. We need some other reviews though.
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 email@example.com
Attachment #57980 - Flags: review+
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 ago → 17 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
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.