23705 - choose file dialog fails to paste japanese text

Status: VERIFIED FIXED

(SeaMonkey :: Preferences, defect, P3)

Description

[Allan Masri]

with Win98ja, macOS 8.5ja, with Mozilla 2000011108:

1. open preferences panel
2. select Advanced | Cache
3. select "Choose Folder" button
4. in choose folder dialog, select a folder with a Japanese name and click OK.

RESULT: Name of the selected folder is displayed incorrectly in field. This also
applies to all similar fields in preferences.

Comment 1

[sairuh (rarely reading bugmail)]

methinks teruko is the appropriate QA contact for this... do let me know if
otherwise!

Comment 2

[Allan Masri]

Well, no, I guess it should be me.

Comment 3

[leger]

Bulk move of all Pref UI component bugs to new Preferences component.  Pref UI 
component will be deleted.

Comment 4

[matt]

Looks like an international problem

Comment 5

[bobj]

Pls update comments and reassign to ftang.

Comment 6

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

ftang,

I looked into this last Friday and there is even an easier way to reproduce it. 
Also this will demonstrate that the problem described in 33862 and 33864 is even 
worse, we are not even able to properly display any non-ASCII file descriptor.
Adding a Unicode file string is good, we also need to make sure it doesn't get 
affected by the internal "escaped" and "unescaped" conversion - see below.


1) create a folder and/or file containing non-ASCII characters (some Latin1    
   chars thrown in for the good measure is all that's needed)

2) go to the Mozilla menu and say "Open new Web location", the hit "Choose File"    
   in the dialog box. 

3) the file path containing non-ASCII chars displays correctly, once you hit    
   enter and Mozilla renders the page, the file path appears in 
   the URL window in escaped form, meaning it no longer displays the non-ASCII 
   characters. The funny part is that one can copy and paste the file 
   resource descriptor in its escaped or unescaped form between the Navigator     
   and Mozilla and it works perfectly. Only Navigator keeps displaying the    
   unescaped string in the URL window.

When debugging I saw some 7 - 10 layers of calls, but the basic problem for 
Latin1 strings happens in

nsStdURL::AppendFileName 

...
        rv = AppendString(buffer,i_FileBaseName,ESCAPED,
                           nsIIOService::url_FileBaseName);
         if (NS_FAILED(rv))
             return rv;
     }

...

where we convert the string to an escaped one. We never save the unescaped 
version of the file path and also don't bother to convert it 
back before displaying it again.

One I could think of is to make sure that we keep a copy of the original string 
and return it back to the JavaScript caller. Another one 
would be unescaping the string in JavaScript before setting the value attribute 
in the UI XUL file...

Comment 7

[Frank Tang]

M16

Comment 8

[Frank Tang]

all the nsIFile and nsIFileSpec related issue should be look together. 

Comment 9

[Frank Tang]

This bug is currently blocked by an assertion inside nsFilePicker.cpp
    NS_ASSERTION(0, "Only load and save are supported modes");

Comment 10

[Frank Tang]

file 35821 for the assertion problem

Comment 11

[Makoto Kato [:m_kato]]

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

Comment 12

[Makoto Kato [:m_kato]]

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

Comment 13

[Frank Tang]

fixed and check in

Comment 14

[Teruko Kobayashi]

Changed QA contact to [e-mail].

Comment 15

[Teruko Kobayashi]

I verified this in 2000042709 Win32 and 2000042710 Linux build.