Closed Bug 11453 Opened 21 years ago Closed 20 years ago
Client-side image map links fail when map name contains space
962 bytes, text/html
2.47 KB, text/html
1002 bytes, text/html
The M8 and M8.5 doesn't understand links that is made of image maps. In the M7 release everything works OK, well this feature anyway :-)
[Moving to ImageLib component and QA Assigning to self.] Since this bug doesn't follow the Bug Writing Guidelines (http://www.mozilla.org/ quality/bug-writing-guidelines.html), I'll only be investigating if I have time, or if a net.volunteer would like to decompose it. If you'd like it investigated sooner, please provide a specific, decomposed test case. Thanks!
Summary: image map links → Client-side image map links fail when map name contains space
Whiteboard: [MAKINGTEST] -- firstname.lastname@example.org → [TESTCASE]
This problem occurs on the 1999081008 build of Mozilla under Windows NT 4 Workstation. Expected behaviour: * Mozilla should use the given client-side image map for the left-hand navigation image Actual behaviour: * For client-side image maps where the name attribute contains a space in it, Mozilla won't find the image map. Other browsers tested: * Opera 3.60 and IE5 both use the client-side imagemap. Attached two test cases, since there is inconsistancy here with Mozilla's current behaviour: client image maps won't be recognised, as shown by the first test case, but hyperlinks to named anchors will work just fine, as seen in the second test case. I was looking around Bugzilla to see if there were any existing bugs related to this one, but I can't find any, so this may a good place for discussion. What should the correct behaviour be in this case? Section 6.2 of the HTML spec allows only letters, digits, hyphens, underscores, colons and periods to be legal characters of a name attribute. If Mozilla encounters illegal characters within a name, what should it do? * Ignore the identifier altogether * Recognise invalid characters as if they are valid, and match the entire identifier * Match the identifier only up to the first illegal character * Match the identifier except for any illegal characters it encounters, which are ignored * Something else...? The first option should probably be abandoned, at least for quirks mode, due to backward compatibility issues. The second option may be undesirable for strict mode.
run2000, excellent investigation! Do you think that 11228 should be marked as a duplicate of this bug?
*** Bug 11228 has been marked as a duplicate of this bug. ***
Yes, of course, you're right. I didn't spot that one.
Image maps are in layout land. Reassigning to vidur, with the idea he will reassign to the appropriate person if its not in his area. -pn
Section 13.6.1 of the HTML 4.0 specification states that map names are CDATA, which section 6.2 indicates can contain internal whitespace.
Yes you're right. I re-read the parts in question. I was getting confused between NAME attributes in HTML and the NAME SGML token. Both anchor names and map names are defined as CDATA, so spaces etc are legal in both. My bad. This leaves us with the original bug that map names with a space in them are not recognised when they should be, and is inconsistant with named anchors in this respect.
I have a fix in my local tree. Waiting for the tree to open to check it in.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Fix checked in on 8/19/1999.
Verified fixed using: 1999082509 Mac OS (8.6) 1999082708 Windows (NT 4.0 SP3) 1999082513 Linux (RH 6.0, GNOME) Specifically, using the 8/11/99 04:16 test case, the clicking within the image map results in the link being followed. --- run2000, should you have the time and inclination, might you be open to giving this a quick once-over and inserting your $.02, should there be any side-issues that you can think of and may wish to check? Thanks!
I've checked that the HTML entity   can be interchanged with spaces. This looks to be fine. The fix for this bug seems to have gone to the other extreme. Spaces inside map names are now completely ignored. From email@example.com's comments, this looks to be bad. I'll file a new bug for this case.
See new bug 12721 for spaces that are ignored but shouldn't be.
This is still not working for me, with build up-to-date with CVS (2000-05-22), Linux RedHat 6.2. Try page http://www.victoriaclippers.com. There is a bar on the left side that has various ferry destination (Victoria BC, Seattle, etc.), fares, schedules, and so on. Items in the sidebar are all imagemaps, where each item has its own map name which contains a space. For some reason, Mozilla treats all those maps as the same, i.e., they all point to the same target -- the one of the very first item, "Victoria BC" -- although according to the page source (and Netscape 4.x) they shouldn't.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Mass moving old milestone bugs to M16
Target Milestone: M10 → M16
Nom. nsbeta2, recc. nsbeta2+. b.c. with HTML 3.2 image maps--key b2 criterion.
Putting on beta2 plus radar
Whiteboard: [TESTCASE] → [nsbeta2+][TESTCASE]
adding testcase kw
Actually, the http://www.victoriaclipper.com problem is slightly different. We're matching the image to the right client-side image map, but the enclosing anchor element seems to takes precedence in our world. I'm not exactly sure why there is an anchor element (with href="victoria.html") surrounding the images and maps, but it seems that our behavior with respect to it is different for Nav 4.x and IE's.
The enclosing anchor closest to the root takes precedence since we deal with anchor event handling in the bubbling pass. Joki and I discussed a fix for this problem (and others related to nested anchors). We need to move the anchor event processing out of nsGenericHTMLElement::HandleDOMEventForAnchor and into the EventStateManager. Anchors would simply set state on the EventStateManager during the bubbling pass (a call to a method like EventStateManager::SetCurrentAnchorContent or some such name) and we'd deal with triggering the link in the EventStateManager after content event handling. As a result, the anchor furthest from the root would win and we'd match Nav 4.x and IE behavior. The fix involves enough risk that I'd recommend that it not go into beta2. Nominating this bug for beta3 and removing the nsbeta2+ designation so that it can be pushed out of this beta.
Whiteboard: [nsbeta2+][TESTCASE] → [TESTCASE]
M16 has been out for a while now, these bugs target milestones need to be updated.
Putting on [nsbeta2-] radar. Not critical to beta2. Adding "relnote" keyword for PR2 release. Please let us know if any other top sites will run into this problem.
Whiteboard: [TESTCASE] → [TESTCASE][nsbeta2-]
Reassigning to Joki...
Assignee: vidur → joki
Status: REOPENED → NEW
I am the virtual joki.
Assignee: joki → heikki
20 years ago
Status: NEW → ASSIGNED
Per discusion with Nisheeth, marking nsbeta3+. Will email ekrock to verify.
Whiteboard: [TESTCASE][nsbeta2-] → [TESTCASE][nsbeta2-][nsbeta3+]
I believe this bug has been fixed, as vidur said. The problem with ignoring spaces in image map links is been covered by bug 12721. I believe the problem with http://www.victoriaclippers.com is covered by bug 30178.
Whiteboard: [TESTCASE][nsbeta2-][nsbeta3+] → [TESTCASE][nsbeta2-][nsbeta3+][fixed?]
Marking FIXED, see my previous comment.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago → 20 years ago
Resolution: --- → FIXED
Whiteboard: [TESTCASE][nsbeta2-][nsbeta3+][fixed?] → [TESTCASE][nsbeta2-][nsbeta3+]
verified in the following builds: Mac - 2000090508 Win - 2000090608 Linux - 2000090621
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.