Closed Bug 66868 Opened 24 years ago Closed 21 years ago

Location of profile is incorrect shown when the path contains non-ascii chars

Categories

(MailNews Core :: Internationalization, defect, P3)

Product:
MailNews Core
Component:
Internationalization
Platform:
All
Windows 2000
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.7alpha

People

(Reporter: m_kato, Assigned: smontagu)

References

Details

(Keywords: intl)

Attachments

(4 files)

screenshot
6.31 KB, image/jpeg
Details
Fix for problem
3.36 KB, patch
dougt
: review+
tor
: superreview+
Details | Diff | Splinter Review
Use attribute wstring unicodePath;
1.84 KB, patch
Details | Diff | Splinter Review
Use attribute AString unicodePath;
3.47 KB, patch
mkaply
: review+
mscott
: superreview+
Details | Diff | Splinter Review 
ENVIRONMENT
===========
Windows 2000
Probably, this will reproduce on Windows9x/Mac.

REPRO STEP
==========
1. Create JPN username profile by [Computer Management] applet of Control Panel
2. Relogon as 1. user
3. Run Mozilla
4. Create mail account.
5. Select [Task] - [Mail]
6. Select [Edit] - [Mail/News Account Settings]
7. Select [Server] item of left panel

RESULT
======
See attached JPG.
Attached image screenshot — 

    
  
Keywords: intl

    
  
QA Contact: esther → momoi

    
    

    
  
Marina or Xianglan, please test and confirm if reproducible.

    
    

    
  
Confirmed the bug. I can reproduce it on my WinNT4.0-J with 2001-01-29-08-mtrunk 
build.
Status: UNCONFIRMED → NEW
Ever confirmed: true

    
    

    
  
This problem also can be reproduced by login to the machine using an ASCII
username but creating a mozilla profile in Japanese.

    
    

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

    
    

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

    
    

    
  
Changed the component to i18n.
Component: Account Manager → Internationalization

    
    

    
  
Adding nsbeta1 keyword, and cc: jenm.

This looks like something we want to get fixed for beta 1.

Racham - Please assign priority to P2, and milestone M0.9.1
Keywords: nsbeta1

    
    

    
  
Besides the fact that it looks wrong, does anything bad happen because of this?

    
    

    
  
No functions are broken because of this. However, the display problem appears on 
several windows where local directory path is shown, like mail server setting 
window, local folder account setting window and News server setting window. And 
it can be reproduced by either log on system using a non-ASCII username or 
launching browser using a non-ASCII profile name, which is pretty common among 
non-English spoken users. 

    
    

    
  
marking nsbeta1+ and moving to 0.9.2
Priority: -- → P3
Whiteboard: [nsbeta1+]
Target Milestone: --- → mozilla0.9.2

    
    

    
  
Changing QA Contact to ji.
QA Contact: momoi → ji

    
    

    
  
All platforms.
Hardware: PC → All

    
    

    
  
moving to 0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3

    
    

    
  
moving to 0.9.4
Target Milestone: mozilla0.9.3 → mozilla0.9.4

    
    

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

    
    

    
  
Mail news triage meeting --> .9.5
Target Milestone: mozilla0.9.4 → mozilla0.9.5

    
    

    
  
Marking nsbranch- as it was decided in the August bug triage that we wouldn't
have eenough time in eMojo to fix this.  Let's revisit for MachV.


Keywords: nsbranch-

    
    

    
  
moving to 0.9.6

    
    

    
  
really moving to 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6

    
    

    
  
moving to 1.0
Target Milestone: mozilla0.9.6 → mozilla1.0

    
  
Blocks: 104166

    
    

    
  
Nominating for nsbeta1, this is very ugly.
Keywords: nsbeta1

    
  
Blocks: 107067

    
  
Keywords: nsbranch-

    
  
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [nsbeta1+]

    
  
Blocks: 10706, 122274
No longer blocks: 107067
Status: NEW → ASSIGNED
Keywords: nsbeta1+ → nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.2

    
    

    
  
Why was this left unfixed while bug 57762 was fixed?

    
    

    
  
See also bug 72736, and bug 92109.

    
    

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

    
    

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

    
  
Summary: Location of profile is incorrect shown when using JPN username → Location of profile is incorrect shown when the path contains non-ascii chars

    
  
Blocks: 157673

    
    

    
  
move nsbeta1- to nsbeta1, please consider this as nsbeta1+ adt3 for m1.2final
release
Keywords: nsbeta1- → nsbeta1

    
    

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

    
    

    
  
Paths to helper apps are affected, too.
2002091014 trunk for MacOS9.x.

    
    

    
  
Racham, would you like to reassign this to me? We decided at the intl bug triage
meeting that we would like to fix this for the next release.

    
    

    
  
reassigning to smontagu
Assignee: racham → smontagu
Status: ASSIGNED → NEW

    
    

    
  
changing qa contact
QA Contact: ji → marina

    
    

    
  
i18n triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-

    
    

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

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Fix for problem
        — 
          — Splinter Review
      

    


  
The bug here is that nsifilespecs only do native chars, so Javascript can't
handle them.

Easy fix for now is to add unicode queries and sets for nsifilespec.

    
  

        Attachment #133046 -
        Flags: review?(dougt)

    
    

    
  
Comment on attachment 133046 [details] [diff] [review]
Fix for problem

how about just converting to use nsIFile?

    
    

    
  
> how about just converting to use nsIFile

Ha ha. Seriously.

I investigated this a little bit and the directory references come from deep
inside mailnews, so this would be nontrivial.

I'm not in a position where I can remove nsifilespec from all of mailnews for
this bug.

So I'd like to do  a quick fix for this.

    
    

    
  
Comment on attachment 133046 [details] [diff] [review]
Fix for problem

Can you do this convertion in JS without adding new methods to nsFileSpec?

I would rather not add any new methods to this interface, but if we must, we
must.

    
    

    
  
the problem is that the conversion has to be to the file system charset using
the OS method of converting to that charset.

I could do unicode conversions in Javascript, but I wouldn't know what charset
to convert to.

By using the code that was added to nsifile, I'm guaranteed to be doing the
right thing(TM) with regards to native file system charset.

    
    

    
  
Comment on attachment 133046 [details] [diff] [review]
Fix for problem

r=dougt.

        Attachment #133046 -
        Flags: review?(dougt) → review+

    
  

        Attachment #133046 -
        Flags: superreview?(sspitzer)

    
  

        Attachment #133046 -
        Flags: superreview?(sspitzer) → superreview?(tor)

    
  

        Attachment #133046 -
        Flags: superreview?(tor) → superreview+

    
    

    
  
mkaply, is this patch ready to go for the trunk? I can drive it in if you think
it is. 

    
    

    
  
I definitely think it is.

I've no idea why I didn't check it in previously.

I can't checkin over the holiday, so if you could get it in, that would be great.

    
    

    
  
I checked this into the 1.7a trunk.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.2alpha → mozilla1.7alpha

    
    

    
  
>+	wstring getUnicodePath();
>+	void setUnicodePath(in wstring aUnicodePath);
Umm... this should have been attribute wstring unicodePath; surely?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
  

        Attachment #138384 -
        Flags: superreview?(mscott)

        Attachment #138384 -
        Flags: review?(mkaply)

    
    

    
  
Why not just use AString to avoid explicit strdup and null-checking? This is not
used in any speed-critical place, is it? 

+	native = mFileSpec.GetNativePathCString();
+	NS_CopyNativeToUnicode(native, unicode);
+	*aUnicodePath = nsCRT::strdup(unicode.get());
+	if (!*aUnicodePath)
+		return NS_ERROR_OUT_OF_MEMORY;



    
    

    
  
Comment on attachment 138410 [details] [diff] [review]
Use attribute AString unicodePath;

Thanks for cleaning this up. This looks much better.

        Attachment #138410 -
        Flags: superreview+

    
    

    
  
Comment on attachment 138410 [details] [diff] [review]
Use attribute AString unicodePath;

r=mkaply

        Attachment #138410 -
        Flags: review+

    
    

    
  
Comment on attachment 138384 [details] [diff] [review]
Use attribute wstring unicodePath;

clearing obsolete requests

        Attachment #138384 -
        Flags: superreview?(mscott)

        Attachment #138384 -
        Flags: review?(mkaply)

    
    

    
  
Fix checked in, thanks especially to jshin, it's always good to be able to
remove code from mozilla ;-)
Status: REOPENED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED
Product: MailNews → Core

    
    

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

    
    

    
  
*** Bug 221908 has been marked as a duplicate of this bug. ***
Product: Core → MailNews Core

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: