202366 - Problem with profile location and non-latin User Name in Mozilla 1.4+/Phoenix

Status: RESOLVED WORKSFORME

(Core Graveyard :: Profile: BackEnd, defect)

Description

[Alexey Pavlov]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401

I have problem with profile location.
I have non-latin characters in my window's UserName (russian).

Due this (i think) default location of profile is
C:\WINDOWS\Mozilla\ (%WinDir%\Mozilla)

instead of 

C:\Documents and Settinds\Application Data\<UserName>\Mozilla
%APPDATA%\Mozilla

Versions under 1.4a (1.3) works perfectly, but 1.4a (+ all nigthly builds and
all Phoenix/Firebird builds) has this bug in profile management.


Reproducible: Always

Steps to Reproduce:
1. Create user with non-latin characters in user name (my variant - russian)
2. Install Mozilla (1.4+)
3. Find default profile location

Actual Results:  
Losing old profiles and inconveniences under WindowsXP Fast User Switching.

Expected Results:  
Each user must have own default profile in %APPDATA%\Mozilla folder

This profile bug present in

Mozilla 1.4+
Phoenix/Firebird 0.5+

Comment 1

[Lukasz Kobylinski]

If the account with non-latin characters doesn't have administrator privileges 
(and therefore write rights to folders beneath C:\Documents and 
Settings\UserName) Mozilla won't start at all - just show the logo for a 
moment and quit immediately.

Comment 2

[Lukasz Kobylinski]

Attachment: Patch for function MakeUpperCase (bug 202366)

It turns out, that the problem was in MakeUpperCase function in
mozilla/xpcom/io/SpecialSystemDirectory.cpp. char * was used there instead of
TCHAR, and functions incompatible with non-latin character sets (islower,
toupper).

Comment 3

[Doug Turner (:dougt)]

to me.

Comment 4

[Doug Turner (:dougt)]

Comment on attachment 128630 [details] [diff] [review]
Patch for function MakeUpperCase (bug 202366)

dan, can you give this a once over?  It looks correct to me.

Comment 5

[Daniel Veditz [:dveditz]]

Comment on attachment 128630 [details] [diff] [review]
Patch for function MakeUpperCase (bug 202366)

I have a few concerns here. First, why are we uppercasing things to start with?
It's error-prone (potential dataloss as some accented lowercase letters don't
have uppercase equivs) and the resulting all-uppercase name is ugly besides.

Mozilla is not compiled with the UNICODE flag so on the surface switching to
tchar shouldn't have had an effect, and I think it would be better to leave
them as explicit narrow strings to make clear what's going on. So why does it
work? Depending on the settings the tchar macros can call multi-byte equivalent
functions instead. Going this route makes me want this tested in a lot of
cases, including Win9x vs win2K+ and definitely on a japanese OS.

I'm not sure why we've got the complicated MakeUpperCase() routine going char
by char with a bunch of conditions in the first place -- simply use CharUpper()
and you're guaranteed to get the system locale, handle MBCS just fine, and
uppercase the string in one shot.

Comment 6

[Daniel Veditz [:dveditz]]

Is the system locale set to Russian? Or is the machine set to a Western Europe
(Latin-1) locale and you're using characters not in Latin-1? If we processed
filenames in Unicode that'd be no problem, but since we're manipulating files as
narrow strings any Unicode characters not in the base character set will get
stripped/replaced as we manipulate it.

To get WinXP to work 100% correctly we should use only Unicode filenames and
explicitly call the "W" variant of WINAPI functions. But those don't work on
Win9x/ME systems so we'd then have to have
   if (is9x)
   {
      lossyconvertToNarrow():
      winapiA();
   }
   else
      winapiW();

everywhere.

Comment 7

[Lukasz Kobylinski]

I don't know if it is necessary to convert to upper case but if so, CharUpper
works for me and it is indeed a better way to do it.

Comment 8

[Lukasz Kobylinski]

Attachment: Patch replacing MakeUpperCase by CharUpper

This changes all references to MakeUpperCase to CharUpper (tested on Polish
Win98, XP and English Win2000).

Comment 9

[Lukasz Kobylinski]

Attachment: MakeUpperCase->CharUpper

Sorry, forgot to take out unused variables.

Comment 10

[Asa Dotzler [:asa]]

Does this need further reviews? The obsoleted patch has a review request. Is
that still relevant?

Comment 11

[Asa Dotzler [:asa]]

Comment on attachment 128630 [details] [diff] [review]
Patch for function MakeUpperCase (bug 202366)

1.5b shipped. moving request forward. Is this request still valid?

Comment 12

[Daniel Veditz [:dveditz]]

Comment on attachment 130264 [details] [diff] [review]
MakeUpperCase->CharUpper

sr=dveditz

I'm happy with this one. Whatever brokenness there may be in comparing
uppercased filenames is still there, but at least it handles the OS charset OK
now.

helpful note: set the review flag to "?" when you're seeking reviews, otherwise
people are likely to not notice a patch was added.

Comment 13

[Doug Turner (:dougt)]

Comment on attachment 130264 [details] [diff] [review]
MakeUpperCase->CharUpper

what dan said.

Comment 14

[Asa Dotzler [:asa]]

Comment on attachment 130264 [details] [diff] [review]
MakeUpperCase->CharUpper

a=asa (on behalf of drivers) for checkin to Mozilla 1.5

Comment 15

[[e-mail]]

(In reply to comment #5)
>First, why are we uppercasing things to start with?
I would have preferred to remove the MakeUpperCase completely too...

Comment 16

[Marcin Gorycki]

Still broken for me in Mozilla 1.6, Firefox 0.8 and Thunderbird 0.5. OS is XP
Home Polish

Comment 17

[Adrian Pavlykevych]

I'm still seeing this bug on Windows XP Russian SP1 with Thunderbird 0.5+ (20040312) and Firefox 0.8

Comment 18

[Benjamin Smedberg]

[e-mail]: only drivers may mark bugs as blocking+. You should mark as
blocking? if you want this bug to be considered a release-blocker.

However, without another patch or a further analysis of the problem, we can't
help much. When you say you "still see this", what do you see?

Comment 19

[Adrian Pavlykevych]

[e-mail] >However, without another patch or a further analysis of the
problem, we can't help much. When you say you "still see this", what do you see?

Well, I'm not in position to provide patches, but I can confirm that neither
Firefox 0.8 nor Thunderbird 0.5+ (April 2004) can store their profile data in
Application Data directory in the user profile under Windows XP SP1 Russian, if
user name (profile directory) is e.g. in Cyryllic.

Both programs _silently_ fall back to WinNT\Profiles\ directory.

This issue makes almost impossibe to have per-user configurations without
resorting to manual profile selection.

I'll be more then happy to provide additional details/debugging, if asked to do so.

Comment 20

[Lukasz Kobylinski]

The patch is not included in FireFox 0.8, Thunderbird 0.5 or Mozilla 1.6. You
should check the latest versions to see if it works (Thunderbird 0.6, Mozilla
1.7RC1 at the moment).

Comment 21

[Jungshik Shin]

The patch here  wouldn't fix the problem. Without fixing bug 162361, Mozilla is
stuck with the character repertoire of the current system locale even on Win 2k
and Win XP (which are Unicode-based) when it comes to the filename handling. 
For instance, with the system locale set to French, there's no way to write to
and read from files with
Russian/Chinese/Hebrew/Arabic/Japanese/Korean/Hindi/Tamil names even though the
OS has the full capability to handle all of them.

 

Comment 22

[Adrian Pavlykevych]

Regarding comment #21:
Well I suspect that most bug reports attributed to this bug are for people, who
try to use login names in _same_ language as system locale in Windows. So
question about e.g. Russian login on Chineese locale is _very_likely_ a corner case.

Comment 23

[Jungshik Shin]

> try to use login names in _same_ language as system locale in Windows

well, note that there are a bunch of languages/scripts for which there's no
'legacy Windows code page' at all.  Besides, Russian users wanting to have their
login names in Russian on a __shared__ Win XP (whose system locale is English)
are not that many but not very rare, either. 

Comment 24

[OstGote!]

see new bugs: bug 247367, bug 247377

Comment 25

[timeless]

Comment on attachment 130264 [details] [diff] [review]
MakeUpperCase->CharUpper

2004-03-02 00:20
mozilla/xpcom/io/SpecialSystemDirectory.cpp	1.9

Comment 26

[Doug Turner (:dougt)]

mass reassigning to nobody.

Comment 27

[(not currently active) Ted Mielczarek]

I believe we fixed this as part of bug 396209. (bent duped bug 396199 to that bug)