46190 - Target (Named) Anchors with Spaces are broken, HREF doesn't navigate to target

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[David Ciemiewicz]

Clicking on an HREF reference to a named anchor with spaces should scroll the
page to bring the table element into view.

This is broken in M16, which I downloaded on July 22, 2000 for Windows NT.
This works in Netscape Communicator 4.61

<a href="#multi part name with spaces">Click Here!</a>
. . .
<table>
<tr>
<td><a name="multi part name with spaces"></a>
<p>some text
</td>
</tr>
</table>

Comment 1

[David Ciemiewicz]

Attachment: Test case with targets inside and outside table

Comment 2

[Jeff Bailey]

I see this with Linux 2000072113 so I'm confirming.  However, I don't know if
this is a real bug or not.  Section 6.2 of the HTML 4.01 spec does include a
space in the list of valid characters for the "NAME" attribute.  Section 2.4.3
of rfc2396 specifically disallows spaces in URIs.

For your reference:
http://www.ietf.org/rfc/rfc2396.txt
http://www.w3.org/TR/html4/types.html#type-cdata

Comment 3

[Jeff Bailey]

Bad typo sorry, that should say section 6.2 does not include a space in the list
of valid...

Comment 4

[Mats Palmgren (inactive)]

Duplicate of bug 11453 ?

Comment 5

[David Ciemiewicz]

This bug may be related to the map bug referenced.

The discussion of CDATA at http://www.w3.org/TR/html4/types.html#type-cdata is 
ambiguous. It is implied that <space> is valid character since it is "part of 
the document character set" and "user agents may leading and trailing 
whitespace" and "replace each carriage return and linefeed with a single space".

However <space> is specifically left out of the NAME definition and is 
specifically left out from the URI and # fragment discussion.

BUT <space> may be encoded as %20 and based on the discussion in 6.2,
"replace character entities with characters" (i.e. %20 with <space>).

To be pedantic, no, there should be no unescaped spaces.  HOWEVER, legacy
improper use, place the fact that every other browser on the planet does
the right thing, plus the fact that it is relatively simple to have the
user agent automagically escape spaces to %20 when referencing external
documents and internal document fragments, the best thing would be to
support spaces in this instance because of the number of websites that
will break, otherwise.  I know it ain't "right" especially in the context
of URI definitions and XML-HTML 1.0 but well, so what.

Comment 6

[harishd]

Triaging Clayton's bug list:
----------------------------

Looks very much like 11453.  Leaving the decision to Vidur. ;)

Comment 7

[Johnny Stenback (:jst)]

Taking this off Vidurs list, I have a fix for this in my tree, will attach
patch. (I think this is a dup but I can't find the other bug!)

Comment 8

[Johnny Stenback (:jst)]

Accepting bug and nominating for beta3, I've seen other sites break because of
this too. Nominating for beta3 based on correctness and backwards compatibility
with 4.x, the fix is really low risk, here's the patch:

Index: base/nsDocShell.cpp
===================================================================
RCS file: /cvsroot/mozilla/docshell/base/nsDocShell.cpp,v
retrieving revision 1.173
diff -u -r1.173 nsDocShell.cpp
--- nsDocShell.cpp      2000/07/21 23:44:38     1.173
+++ nsDocShell.cpp      2000/07/26 02:04:24
@@ -3103,6 +3103,12 @@

     if (!sNewRef.IsEmpty())
     {
+        char *tmp = sNewRef.ToNewCString();
+
+        sNewRef.Assign(NS_ConvertUTF8toUCS2(nsUnescape(tmp)));
+
+        nsMemory::Free(tmp);
+
         nsCOMPtr<nsIPresShell> shell = nsnull;
         rv = GetPresShell(getter_AddRefs(shell));
         if (NS_SUCCEEDED(rv) && shell)

Comment 9

[Nisheeth Ranjan]

Marking nsbeta3+...

Comment 10

[Johnny Stenback (:jst)]

Fix checked in, marking FIXED.

Comment 11

[Chris Petersen]

Verified fixed in the Aug 24th build.

Comment 12

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

SPAM. HTML Element component deprecated, changing component to Layout. See bug
88132 for details.