Closed
Bug 406498
Opened 17 years ago
Closed 17 years ago
Firefox 3 doesn't display content with Cyrillic names from FTP folders (FileZilla server)
Categories
(Firefox :: File Handling, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: mishail.mishail, Unassigned)
Details
Attachments
(3 files)
Screenshot of the problem
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007120105 Minefield/3.0b2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007120105 Minefield/3.0b2pre
Firefox 3 doesn't display content with Cyrillic names from FTP folders (FileZilla server).
Such items (with Cyrillic names) just miss in the list.
Setup.
1. Client side: Firefox 3 (beta1 for ex.)
2. Server side: Filezilla server 0.9.22 + patch which disables UTF-8 support by default, enables it only after get 'OPTS UTF8 ON' (http://sourceforge.net/projects/filezillapv/)
Reproducible: Always
Steps to Reproduce:
Sorry, I can't provide the links to the external ftp servers where this problem can be shown. But it occurs every time in our local network
1. Navigate to the folder with files with Cyrillic names
Actual Results:
Files (and folders) with Cyrillic names are not shown
Expected Results:
Files (and folders) with Cyrillic names are shown in the list
|
Reporter | |
Comment 1•17 years ago
|
||
|
|
Reporter | |
Comment 2•17 years ago
|
||
|
|
Reporter | |
Comment 3•17 years ago
|
||
|
|
Reporter | |
Comment 4•17 years ago
|
||
Comment on attachment 291148 [details]
"View page Source" done in the Firefox 3
><HTML><HEAD><STYLE type="text/css">a.grauw-imageview { -moz-outline: 1px dotted red; padding: 1px; }a.grauw-imageview img.grauw-imageview { display: none; position: absolute; left: 0; max-width: 100%; margin: 0; border: none; }a.grauw-imageview:hover img.grauw-imageview { display: block; }</STYLE></HEAD><BODY><PRE><SPAN>300: <A class="linkifyplus" href="ftp://<server>/Music/Rock/">ftp://<server>/Music/Rock/</A>
>200: filename content-length last-modified file-type
>201: "���%20&%20Co%20-%201993%20-%20���" 0 Sun%2C%2028%20Jun%202007%2000%3A00%3A00 DIRECTORY
>201: "���%20&%20Co%20-%201994%20-%20Live" 0 Sun%2C%2028%20Jun%202007%2000%3A00%3A00 DIRECTORY
>201: "���%20&%20Co%20-%201994%20-%20�����������" 0 Sun%2C%2028%20Jun%202007%2000%3A00%3A00 DIRECTORY
>201: "���%20&%20Co%20-%201995%20-%20...�%20�����" 0 Sun%2C%2028%20Jun%202007%2000%3A00%3A00 DIRECTORY
>201: "���%20&%20Co%20-%201995%20-%20Greatest%20Hits%20(Live)" 0 Sun%2C%2028%20Jun%202007%2000%3A00%3A00 DIRECTORY
>201: "���%20&%20Co%20-%201996%20-%20�������" 0 Sun%2C%2028%20Jun%202007%2000%3A00%3A00 DIRECTORY
>201: "���%20&%20Co%20-%201996%20-%20���������%20����" 0 Sun%2C%2028%20Jun%202007%2000%3A00%3A00 DIRECTORY
>201: "���%20&%20Co%20-%201997%20-%20���������������" 0 Sun%2C%2028%20Jun%202007%2000%3A00%3A00 DIRECTORY
>201: "���%20&%20Co%20-%201998%20-%20�������" 0 Sun%2C%2028%20Jun%202007%2000%3A00%3A00 DIRECTORY
>201: "���%20&%20Co%20-%201998%20-%20�����%20���������" 0 Sun%2C%2028%20Jun%202007%2000%3A00%3A00 DIRECTORY
>201: "���%20&%20Co%20-%202001%20-%20�������%20����!" 0 Sun%2C%2028%20Jun%202007%2000%3A00%3A00 DIRECTORY
></SPAN>
|
|
Reporter | |
Comment 5•17 years ago
|
||
With Firefox 2 all worked fine
|
|
Reporter | |
Updated•17 years ago
|
Version: unspecified → Trunk
|
|
Reporter | |
Comment 6•17 years ago
|
||
Looks like issue happens only with
intl.charset.default=UTF-8
When intl.charset.default=windows-1251 all works fine.
Severity: normal → minor
|
||
Comment 7•17 years ago
|
||
Could be related to https://bugzilla.mozilla.org/show_bug.cgi?id=309343 somehow…
|
||
Comment 8•17 years ago
|
||
FYI.
Extension of FireFTP is available for the long-lived non-ascii pathname issue in FTP.
> http://fireftp.mozdev.org/
> http://fireftp.mozdev.org/help.html
Creator of FireFTP says as follows in his Help.
--------------------------------------------------------------------------
What is Server Encoding?
Not all servers around the globe use the same characters when talking to FireFTP. There are Japanese, Russian, Chinese, and many more languages that have special characters in their languages. This setting defaults to UTF-8 (which *cough* the servers should use *cough*) but some server's are outdated (or not as hip) and use other encodings. So, if you're seeing strange characters on the remote side of FireFTP you can try messing around with this feature until you find the language that your server speaks.
--------------------------------------------------------------------------
|
|
||
Comment 9•17 years ago
|
||
(In reply to comment #6)
> Looks like issue happens only with
> intl.charset.default=UTF-8
> When intl.charset.default=windows-1251 all works fine.
Can "setting View/Character Encoding=windows-1252(while intl.charset.default NE windows-1252)" be another workaround of unexpected display issue of non-ascii FTP file name?
|
|
||
Comment 10•17 years ago
|
||
(In reply to comment #6)
> When intl.charset.default=windows-1251 all works fine.
When non-ascii FTP file name is displayed as expected by the woraround, can the file of non-ascii name be accessed with no problem by link click/save as etc.?
|
|
Reporter | |
Comment 11•17 years ago
|
||
(In reply to comment #10)
> (In reply to comment #6)
> > When intl.charset.default=windows-1251 all works fine.
>
> When non-ascii FTP file name is displayed as expected by the woraround, can the
> file of non-ascii name be accessed with no problem by link click/save as etc.?
>
Yes.
However, I've just checked the behavior with intl.charset.default=UTF-8 using standard complaint Filezilla version (UTF8 mode ON by default, http://forum.filezilla-project.org/viewtopic.php?f=6&t=3345) and problem almost disappeared.
I say "almost" because Firefox doesn't display non-ascii items in the *long* list (i.e. in directory with a lot of items (folders/files). I must do "Reload" and non-ascii items appears only after that.
Not sure how long a list should be to observe such behavior. In my case non-ascii items start from 270th position in the list (and they are not displayed at first attempt)
|
|
||
Comment 12•17 years ago
|
||
> In my case non-ascii items start from 270th position in the list
> (and they are not displayed at first attempt)
While ftp directory content is displayed, two kind of source can be viewed.
(A) View/Page Source => Response data from FTP server for NLST or LIST
(B) CTRL+A(Select All), Context menu/View Selection Source
=> HTML internally generated by Fx to display directory list
All files/directories are seen in (A) and (B) when first attempt?
Different from second atempt(non-scii file is listed as expected)?
|
|
Reporter | |
Comment 13•17 years ago
|
||
Finally I no more able to reproduce this bug. So I mark it as INVALID
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•