63044 - [Choose File] cannot use DBCS filename

Status: VERIFIED FIXED

(Core :: Internationalization, defect)

Description

[Makoto Kato [:m_kato]]

REPRO STEP
==========
1. [Edit] - [Preferences...]
2. [Navigator] tree on [Category]
3. click [Choose File]
4. select Japanese file and click [OK]

RESULT
======
[Location] text field is incorrect.  This problem 
is /xpfe/components/prefwindow/resources/content/prefutilities.js


http://lxr.mozilla.org/seamonkey/source/xpfe/components/prefwindow/resources/con﷒0﷓

 56 function prefNavSelectFile(folderFieldId, stringId, useNative)
 57 {
 58   var folderField = document.getElementById(folderFieldId);
 59   var dlgString = stringId ? bundle.GetStringFromName(stringId) : '';
 60   var file = getFileOrFolderSpec( dlgString, false );
 61   if( file != -1 )
 62   {
 63     /* XXX nsILocalFile doesn't have a URL string */
 64     if (useNative)
 65     {
 66       folderField.value = file.unicodePath;
 67     }
 68     else
 69     {
 70       // Hack to get a file: url from an nsIFile
 71       var tempFileSpec = Components.classes
["@mozilla.org/filespec;1"].createInstance(Components.interfaces.nsIFileSpec);
 72       tempFileSpec.nativePath = file.unicodePath;
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 73 
 74       try {
 75         var url = tempFileSpec.URLString;
 76         if( url )
 77           folderField.value = url;
 78       }
 79       catch(e) {
 80       }
 81     }
 82   }
 83 }

Comment 1

[Makoto Kato [:m_kato]]

Attachment: fix code

Comment 2

[nhottanscp]

What functionaries are affected by this (i.e. how to confirm the bug)?

Comment 3

[Teruko Kobayashi]

I can reproduce this on 12-12 Mtest build.

Comment 4

[nhottanscp]

r=nhotta

I have a question for the comment.
// file.URL cannot convert DBCS filename.  So we uses nsIFileURL

Is that DBCS specific or generic to non Latin1?
Also, I think "nsIFileSpec.URLString" instead of "file.URL".
So, please change the comment if you agree.

Comment 5

[Makoto Kato [:m_kato]]

sorry, this is mistake comment :-).  I forgot that its function is not 
implement on other than Windows.  And it will crash when it cancels filepicker.
I attach new fix

Comment 6

[Makoto Kato [:m_kato]]

Attachment: fix code

Comment 7

[nhottanscp]

>And it will crash when it cancels filepicker.
I am not clear, crashes with your old patch or even without your any of the patches?

Comment 8

[Makoto Kato [:m_kato]]

Using old patch, it will crash when you cancel filepicker dialog.

Comment 9

[nhottanscp]

r=nhotta
So you changed getFileOrFolderSpec() to return -1 if the user canceled. Although
not related to your change, the function's return value is not consistent. It
returns "false" or -1 for error and fp.file for success.

Comment 10

[Makoto Kato [:m_kato]]

Sorry, hotta-san, could you review one more? (old code is not smart like your 
comment).

Comment 11

[Makoto Kato [:m_kato]]

Attachment: new fix at 2001/01/19

Comment 12

[nhottanscp]

I think the return value should be unified instead of changing the caller to
check both cases (e.g. file != -1 && file != null).

Comment 13

[Makoto Kato [:m_kato]]

Sure.
It will be super-view process by old patch.
Thanks, hotta san. 

Comment 14

[Alec Flett]

sr=alecf on the 2nd patch listed here.

Comment 15

[Makoto Kato [:m_kato]]

check in

Comment 16

[Yuying Long]

The Japanese file name shows like in [location] text field:
file:///C:/Yuying2/TESTPAGE/%83e%83X%83g.html
I don't know if it is correct or not though, cause Japanese file name display 
like this way around a lots of place in N6.

Comment 17

[Yuying Long]

I re-open the bug cause DBCS file name still not display glyph.  Please change 
the status if it is acceptable.

Comment 18

[Makoto Kato [:m_kato]]

Yuying, your comment is other bug.  Because this bug is what Mozilla cannot 
open DBCS file name.
Please open new bug.

Comment 19

[Yuying Long]

Verified on 05-11 trunk build.