Last Comment Bug 46190 - Target (Named) Anchors with Spaces are broken, HREF doesn't navigate to target
: Target (Named) Anchors with Spaces are broken, HREF doesn't navigate to target
Status: VERIFIED FIXED
[nsbeta3+] Have fix
:
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: x86 Windows NT
: P3 normal (vote)
: ---
Assigned To: Johnny Stenback (:jst, jst@mozilla.com)
: Chris Petersen
Mentors:
http://www.xicomputer.com/products/we...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2000-07-22 14:43 PDT by David Ciemiewicz
Modified: 2001-09-05 10:47 PDT (History)
0 users
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Test case with targets inside and outside table (3.22 KB, text/html)
2000-07-22 14:44 PDT, David Ciemiewicz
no flags Details

Description David Ciemiewicz 2000-07-22 14:43:06 PDT
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 2000-07-22 14:44:01 PDT
Created attachment 11768 [details]
Test case with targets inside and outside table
Comment 2 Jeff Bailey 2000-07-22 17:02:45 PDT
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 2000-07-22 17:23:24 PDT
Bad typo sorry, that should say section 6.2 does not include a space in the list
of valid...
Comment 4 Mats Palmgren (vacation) 2000-07-22 19:37:59 PDT
Duplicate of bug 11453 ?
Comment 5 David Ciemiewicz 2000-07-22 21:51:32 PDT
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 2000-07-25 10:21:27 PDT
Triaging Clayton's bug list:
----------------------------

Looks very much like 11453.  Leaving the decision to Vidur. ;)
Comment 7 Johnny Stenback (:jst, jst@mozilla.com) 2000-07-25 19:03:43 PDT
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, jst@mozilla.com) 2000-07-25 19:16:55 PDT
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 2000-08-08 01:56:57 PDT
Marking nsbeta3+...
Comment 10 Johnny Stenback (:jst, jst@mozilla.com) 2000-08-18 00:32:37 PDT
Fix checked in, marking FIXED.
Comment 11 Chris Petersen 2000-08-24 19:45:12 PDT
Verified fixed in the Aug 24th build.
Comment 12 Heikki Toivonen (remove -bugzilla when emailing directly) 2001-09-05 10:47:02 PDT
SPAM. HTML Element component deprecated, changing component to Layout. See bug
88132 for details.

Note You need to log in before you can comment on or make changes to this bug.