505037 - ".&" or some control chars in filenames of a local file causes it to break directory view when you browse to it or go directly.

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Ian Stirling.]

Create a file containing the affected chars - in shell

>.\&
>jfjfj.\&jjdjdjd
>fkfkfkf.\&

all exhibit the problem
Now simply open file:///whateverthedirectory is.
Observe broken XML warning.

On further testing - a number of single char filenames seem to be broken.
64-255 seem clean - however 0-10 have one or more broken chars.
I have not tested fully to get the whole range of affected chars, or multichar strings.
(On linux, only NUL and / are forbidden filename chars)

Comment 1

[Ian Stirling.]

Error: not well-formed
Source File: file:///home/user/d1/
Line: 215, Column: 101
Source Code:
 <td sortable-data="2.&amp;djdjdj"><a class="file" href=".&amp;djdjdj"><img src="moz-icon://.&djdjdj?size=16" alt="File:" />.&amp;djdjdj</a></td>

A paste from the error console, showing the problem is in the incorrect escaping of the filename when making the icon.
moz-icon://.&djdjdj?size=16
Should be
moz-icon://.&amp;djdjdj?size=16

unless I'm confused.

Comment 2

[Ian Stirling.]

./netwerk/streamconv/converters/nsIndexedToHTML.cpp lines 933 -

 I think this is around the location of this bug - but I'm not quite sure what the syntax is that I need to fix it.
<pre>
  if (type == nsIDirIndex::TYPE_FILE || type == nsIDirIndex::TYPE_UNKNOWN) {
        pushBuffer.AppendLiteral("<img src=\"moz-icon://");
        PRInt32 lastDot = escapeBuf.RFindChar('.');
        if (lastDot != kNotFound) {
            escapeBuf.Cut(0, lastDot);
            AppendUTF8toUTF16(escapeBuf, pushBuffer);
        } else {
</pre>
Before AppendUTF8toUTF16(escapeBuf, pushBuffer) - does this require something to properly escape &'s that occur after the lastDot?

Comment 3

[(not currently active) Ted Mielczarek]

Repeating what I said on IRC:
escapeBuf is URI encoded, but not HTML encoded, so characters like & that need to be escaped to be stuck in HTML will still be there. You might be able to use the htmlEscapedURL variable instead, which has HTML characters escaped as well.

Comment 4

[Hugues Fournier (french l10n team)]

Attachment: Patch against mozilla-central

I encountered the same bug and drawn the same conclusions.
Here is a proposition of patch against the trunk (that works too against 1.9.1/1.9.2)

Comment 5

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/b74512cb7fee

Comment 6

[Ian Stirling.]

Broken again - Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7

Same testcases as original bug cause similar problem.
error console - 

Error: not well-formed
Source File: file:///home/user/test
Line: 210, Column: 83
Source Code:
 <td sortable-data="2.&amp;"><a class="file" href=".&amp;"><img src="moz-icon://.&?size=16" alt="File:" />.&amp;</a></td>

Comment 7

[Hugues Fournier (french l10n team)]

Ian, the bug has been fixed only on the trunk (you can test it in the trunk nightlies).. not on the 1.9.1 branch. 

So it is not broken again, it has just not been fixed in Firefox 3.5 (neither in Firefox 3.6). Except if you absolutely want the fix backported to Firefox 3.5/3.6, I would suggest you to reclose it.

Comment 8

[Ian Stirling.]

Apologies - I'd assumed that it was fixed on 3.5 - but this was the first upgrade i'd done in some time, hence assumed it was a regression. Thanks.