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

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[bjorn]

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 :-)

Comment 1

[Eli Goldberg]

[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!

Comment 2

[Nicholas Cull]

Attachment: Test case showing client side image maps with space in name not being found.

Comment 3

[Nicholas Cull]

Attachment: Additional test case showing that named anchors with space in them are ok.

Comment 4

[Nicholas Cull]

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.

Comment 5

[Nicholas Cull]

Attachment: Corrected test case 1.

Comment 6

[Nicholas Cull]

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.

Comment 7

[Eli Goldberg]

run2000, excellent investigation!

Do you think that 11228 should be marked as a duplicate of this bug?

Comment 8

[Nicholas Cull]

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

Comment 9

[Nicholas Cull]

Yes, of course, you're right. I didn't spot that one.

Comment 10

[pnunn]

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

Comment 11

[tor]

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.

Comment 12

[Nicholas Cull]

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.

Comment 13

[vidur (gone)]

I have a fix in my local tree. Waiting for the tree to open to check it in.

Comment 14

[vidur (gone)]

Fix checked in on 8/19/1999.

Comment 15

[Eli Goldberg]

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!

Comment 16

[Nicholas Cull]

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 [e-mail]'s comments, this
looks to be bad. I'll file a new bug for this case.

Comment 17

[Nicholas Cull]

See new bug 12721 for spaces that are ignored but shouldn't be.

Comment 18

[Davor Cubranic]

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.

Comment 19

[David Krause]

Mass moving old milestone bugs to M16

Comment 20

[ekrock's old account (dead)]

Nom. nsbeta2, recc. nsbeta2+. b.c. with HTML 3.2 image maps--key b2 criterion.

Comment 21

[Jim Roskind]

Putting on beta2 plus radar

Comment 22

[Blake Ross]

adding testcase kw

Comment 23

[vidur (gone)]

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.

Comment 24

[vidur (gone)]

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.

Comment 25

[Mike]

M16 has been out for a while now, these bugs target milestones need to be 
updated.

Comment 26

[Jay Patel [:jay]]

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.

Comment 27

[Johnny Stenback (:jst)]

Reassigning to Joki...

Comment 28

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I am the virtual joki.

Comment 29

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Per discusion with Nisheeth, marking nsbeta3+. Will email ekrock to verify.

Comment 30

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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.

Comment 31

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Marking FIXED, see my previous comment.

Comment 32

[Paul Wyskoczka]

verified in the following builds:
Mac - 2000090508
Win - 2000090608
Linux - 2000090621