8319 - {compat} Spaces in 'href' atttribute lost in content sink

Status: VERIFIED FIXED

(Core :: DOM: HTML Parser, defect, P4)

Description

[dennis.m.ginley]

Summary: Clicking a link to a page whose filename contains a space won't display
the page.

Steps to reproduce:
0) Launch Viewer
1) Load a page that contains a link to another page whose filename contains a
space. e.g. <A href="Text Color.html">Text Colors</A>
2) Click the link

Result:
* The page does not load, but Viewer claims that it has loaded. The status bar
at the bottom of the window has the message: "<path>/TextColor.html done" Note
that the space between 'Text' and 'Color' has been removed.
* At this point, doing File/View Source opens a window for TextColor.html, so
the Viewer appears to believe that it has loaded the page.
* The terminal window from which the Viewer was launched displays the message:
nsDocumentBindInfo::OnStopBinding: Load of URL '<path>/TextColor.html' failed.
Error code: 1

However, just to make it a little more complicated, 'File/Open/Text Color.html'
works perfectly. The file list displays all the filenames with spaces correctly,
and, after the file loads its name is displayed with the space replaced by %20,
which is what Netscape and IE both do.

Comment 1

[rickg]

The parsing engine is passing the correct link "xxx yyy" to the content sink.
Somewhere in there, it appears to be losing the spaces. Reassign to kipps plate
till I can look at it later. Low priority issue, BTW.

Comment 2

[Hixie (not reading bugmail)]

Note that an href containing a space is invalid. The 'href' attribute should
be URL-encoded, which means that the example you give should really read:

   <A href="Text%20Color.html">Text Colors</A>

Marking this bug {compat}, accepting as M15 (which just means that Kipp will
look at it when he comes back, not that it won't get fixed until M15), lowering
priority and severity, updating summary.

Note: the problem is definitely occuring during the document load (as Rick
says above) -- not during the link processing (after the click).

Comment 3

[John Morrison]

Be aware also of bug #7399 which also concerns spaces in href (although
it is not the same bug as this).

 While I agree that 'URL' should never contain literal space characters
(and the RFC is clear on this point), bug #7399 has some links to a
working draft and some discussions on xml-dev that argue that this may
be (???) the 'new' way. (I hope not).

Comment 4

[Hixie (not reading bugmail)]

The way I interpret those specs, they just say that we should be escaping
illegal characters, not that illegal characters are to be allowed in documents.

Comment 5

[John Morrison]

Yes. I agree. For the i18n reason. My concern is simply with the 'space'
character (%20) -- if Mozilla supports this auto-escaping (IE does already),
then 'spaces' in URL/URI will become quite commonplace -- a de facto standard
contrary to RFC 2396. (Not a good thing, in my (inconsequential) opinion).

Comment 6

[kipp]

It turns out that the content classes (my bad) were stripping off whitespace out
of strings that are url's.

The content should just store what its given, and leave it up to the networking
library to validate urls...

Fixed...

Comment 7

[buster]

mine now

Comment 8

[John Morrison]

And this one is fixed, too. I'm going to re-resolve as FIXED.

Comment 9

[bsharma]

updated qa contact.

Comment 10

[bsharma]

Verified on
build: 2001-05-29-20-Trunk
platform: Win NT

The test case that contains a link to another page whose filename contains a
space loads fine.