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

RESOLVED FIXED in mozilla1.9.3a1

Status

()

Core
Networking
--
major
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: Ian Stirling., Assigned: Hugues Fournier (french l10n team))

Tracking

Trunk
mozilla1.9.3a1
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
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)
(Reporter)

Updated

9 years ago
Summary: ".&" or some control chars in filenames of a file causes it to break directory view when you browse to it or go directly. → ".&" or some control chars in filenames of a localfile causes it to break directory view when you browse to it or go directly.
(Reporter)

Updated

9 years ago
Summary: ".&" or some control chars in filenames of a localfile causes it to break directory view when you browse to it or go directly. → ".&" or some control chars in filenames of a local file causes it to break directory view when you browse to it or go directly.
(Reporter)

Comment 1

9 years ago
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.
(Reporter)

Comment 2

9 years ago
./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?
Component: File Handling → Networking
Product: Firefox → Core
QA Contact: file.handling → networking
Target Milestone: Firefox 3.5 → ---
Version: 3.5 Branch → Trunk
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.
(Assignee)

Comment 4

9 years ago
Created attachment 405678 [details] [diff] [review]
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)
Attachment #405678 - Flags: review?(cbiesinger)
Attachment #405678 - Flags: review?(cbiesinger) → review+

Updated

9 years ago
Keywords: checkin-needed
Assignee: nobody → hugues.fournier
http://hg.mozilla.org/mozilla-central/rev/b74512cb7fee
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
(Reporter)

Comment 6

9 years ago
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>
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 7

9 years ago
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.

Updated

9 years ago
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago9 years ago
Resolution: --- → FIXED
(Reporter)

Comment 8

9 years ago
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.
You need to log in before you can comment on or make changes to this bug.