Closed Bug 11453 Opened 21 years ago Closed 20 years ago

Client-side image map links fail when map name contains space


(Core :: Layout, defect, P3)






(Reporter: bjorn, Assigned: hjtoi-bugzilla)




(Keywords: relnote, testcase, Whiteboard: [TESTCASE][nsbeta2-][nsbeta3+])


(3 files)

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 :-)
Component: Browser-General → ImageLib
QA Contact: leger → elig
[Moving to ImageLib component and QA Assigning to self.]

Since this bug doesn't follow the Bug Writing Guidelines (
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

Whiteboard: [MAKINGTEST] --
Summary: image map links → Client-side image map links fail when map name contains space
Whiteboard: [MAKINGTEST] -- → [TESTCASE]
This problem occurs on the 1999081008 build of Mozilla under Windows NT 4

Expected behaviour:
* Mozilla should use the given client-side image map for the left-hand navigation

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

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
Attached file Corrected test case 1.
Duh! Fixed the first test case, which was pointing to a local image on my
hard drive.

See also bug 11629 and bug 11631, which were found while creating the second
test case.
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.
Assignee: don → pnunn
Assignee: pnunn → vidur
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.
Component: ImageLib → Layout
OS: Windows 98 → All
Hardware: PC → All
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.
Target Milestone: M10
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?

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

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.
Keywords: nsbeta2
Putting on beta2 plus radar
Whiteboard: [TESTCASE] → [nsbeta2+][TESTCASE]
adding testcase kw
Keywords: testcase
Actually, the 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.
Keywords: nsbeta3
Whiteboard: [nsbeta2+][TESTCASE] → [TESTCASE]
M16 has been out for a while now, these bugs target milestones need to be 
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 
Keywords: relnote
Whiteboard: [TESTCASE] → [TESTCASE][nsbeta2-]
Reassigning to Joki...
Assignee: vidur → joki
I am the virtual joki.
Assignee: joki → heikki
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 

I believe the problem with is covered by bug 
Whiteboard: [TESTCASE][nsbeta2-][nsbeta3+] → [TESTCASE][nsbeta2-][nsbeta3+][fixed?]
Marking FIXED, see my previous comment.
Closed: 21 years ago20 years ago
Resolution: --- → FIXED
Whiteboard: [TESTCASE][nsbeta2-][nsbeta3+][fixed?] → [TESTCASE][nsbeta2-][nsbeta3+]
verified in the following builds:
Mac - 2000090508
Win - 2000090608
Linux - 2000090621
You need to log in before you can comment on or make changes to this bug.