163682 - FTP download: non-ascii filename is not shown correctly via "Save Link Target As"

Status: VERIFIED FIXED

(Core :: Internationalization, defect, P1)

Description

[ji]

This is seperated from bug 162377.

Steps to reproduce:
1. go to ftp://10.169.114.243
2. Go to Edit | Preference | Language, select Simplified Chinese (GB2312) as
Character Encoding, so the Chinese filenames can be viewed correctly on
thelisting page.
3. Shift click on the html/text file with Chinese filename or right click on the
file and select Save Link Target As menu, the Chinese filename is always shown
as "File" on Save as dialog.
4. To compare with the result of an English filename, on the same page, click on
"English" folder, Shift click on an English html/text file, you can see the
English filename is shown correctly on Sava as dialog

Comment 1

[Jaime Rodriguez, Jr.]

Is this a Mozilla browser issue only, or will embeddor see the same "Save as
dialog?"  IF embeddors will see this problem, pls nominate as topembed. thanks!

Comment 2

[ji]

Embeddor also has a context menu of "Save Link Target As". Nominating.

Comment 3

[Rui Xu]

Restore bug status which are changed wrong.

Comment 4

[Jaime Rodriguez, Jr.]

Bug status was not changed. The field changes were Priority, Severity, Target
Milestone and the keyword nsbeta1+.

Pls Note: nsbeta1+ indicated to development that this is a good bug to work on,
Mozilla1.0.2 is the milestone in which PjM along with development believes the
bug will be resolved [as Mozilla1.0.1 will be final tomorrow], Severity was not
changed from its default and is probably not "normal" as this would be needed by
a major embeddor (but, it is a QA field, so i will leave @ "normal" and ask that
ji upgrade it to "major"), and last P1, because it is the #1 thing nhotta should
be working on this week.

Comment 5

[ji]

JPG/BMP files have the same problem, modified the summary accordingly.

Comment 6

[ji]

Did more testing, actually download via Save Link Target As menu has problems
with all different file types: .exe/.doc/.html/.txt/.jpg/.bmp/.gif

Comment 7

[nhottanscp]

There are functions in contentAreaUtils.js which seems to handle file names.

642 function getDefaultFileName(aDefaultFileName, aNameFromHeaders,
aDocumentURI, aDocument)
http://lxr.mozilla.org/seamonkey/source/xpfe/communicator/resources/content/contentAreaUtils.js#642

689 function validateFileName(aFileName)
http://lxr.mozilla.org/seamonkey/source/xpfe/communicator/resources/content/contentAreaUtils.js#689


cc to bzbarsky, I need to talk to him to get some info.

Comment 8

[Boris Zbarsky [:bzbarsky]]

This is a dup of bug 161242

Comment 9

[nhottanscp]

Attachment: Add a code to unescape with a charset for a non ASCII file name.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 97705 [details] [diff] [review]
Add a code to unescape with a charset for a non ASCII file name.

Nice!  I forgot all about window._content...

sr=bzbarsky

Comment 11

[[e-mail] (away - not reading bugmail)]

Comment on attachment 97705 [details] [diff] [review]
Add a code to unescape with a charset for a non ASCII file name.

r=jbetak

Naoki, I believe the fallback will return the charset of the top frame (top
content window). 

+	 charset = window._content.document.characterSet

Since aDocument should contain the currently focused frame as you have pointed
out, this scenario is unlikely to occur. 

The top frame might be a good enough fall-back for FTP sites, since they are
not known for using multiple charsets on one page.

I didn't want to complicate things, just document my understanding of what this
code really does in case we would ever need to revisit it.

Comment 12

[Boris Zbarsky [:bzbarsky]]

> Since aDocument should contain the currently focused frame

aDocument is only set when doing "save page as" or "save frame as".  "save link
target as", shift-click, etc (what this bug is concerned with) will always have
a null aDocument.

Comment 13

[nhottanscp]

Do we want "document.commandDispatcher.focusedWindow" instead of
"window._content" then?

Comment 14

[Boris Zbarsky [:bzbarsky]]

Hmm... that would be a good idea, I think.

Comment 15

[Jaime Rodriguez, Jr.]

This is needed by a major embeddor. Marking as Topembed+ per Valeski. 

Comment 16

[nhottanscp]

Attachment: Changed to prefer focusedWindow over window._content.

Comment 17

[[e-mail] (away - not reading bugmail)]

Comment on attachment 97964 [details] [diff] [review]
Changed to prefer focusedWindow over window._content.

r=jbetak

bz, we've seen cases where document.commandDispatcher.focusedWindow == null,
see bug 60406 (relates to some sidebar trickery)

Comment 18

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 97964 [details] [diff] [review]
Changed to prefer focusedWindow over window._content.

sr=bzbarsky

Comment 19

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 97964 [details] [diff] [review]
Changed to prefer focusedWindow over window._content.

a=[e-mail]

Comment 20

[nhottanscp]

checked in to the trunk

Comment 21

[Jaime Rodriguez, Jr.]

ji: can you pls verify this as fixed in the next trunk build? thanks!

Comment 22

[ji]

Verified as fixed on 2002-09-09-04-trunk build.

Comment 23

[nhottanscp]

Attachment: Resolved conflicts for 1.0 branch.

Comment 24

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 98454 [details] [diff] [review]
Resolved conflicts for 1.0 branch.

Carrying over r/sr from trunk patch.
a=[e-mail] for 1.0 branch checkin.  Please change mozilla1.0.2+ to
fixed1.0.2 when checked in.

Comment 25

[Jaime Rodriguez, Jr.]

Marking as "mozilla1.0.2+" per Comment #24 From Randell Jesup.

Comment 26

[nhottanscp]

checked in to 1.0 branch

Comment 27

[ji]

Verified as fixed on 09/12 1.0.2 branch build.

Comment 28

[Boris Zbarsky [:bzbarsky]]

*** Bug 161242 has been marked as a duplicate of this bug. ***