POP: Japanese name folder looks weird after restart

VERIFIED FIXED in mozilla1.0.1

Status

defect
VERIFIED FIXED
17 years ago
7 years ago

People

(Reporter: jeesun, Assigned: naving)

Tracking

({intl, regression})

Trunk
mozilla1.0.1
x86
Windows XP
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt1 rtm] [ETA 07/10])

Attachments

(3 attachments)

Reporter

Description

17 years ago
POP: Japanese name folder looks weird after restart

Steps:
1. Setup a POP account
2. Create a JA name folder (in my case, ねこ - see this in Shift_JIS)
3. The new folder is displayed correctly
4. Exit and restart the browser
5. Notice that the JA folder name looks weird

Note: 
On IMAP account, there's no such problem.
Latin-1 folders look fine after restart.
If you open a POP account in a new profile, a new folder won't show before you
close/reopen mail window (see bug 155658 )
Reporter

Updated

17 years ago
Keywords: intl

Comment 1

17 years ago
>5. Notice that the JA folder name looks weird
Please attach a screen shot.
Reporter

Comment 2

17 years ago
Right below Trash folder, there's "mS" folder. It should show the JA name I
gave upon creation.

Comment 3

17 years ago
This is a regression from 7.0PR1. Jeesun, please find out when this has started.

Reassigned to naving, cc to putterman. Can this be related to the recent POP
folder related change?
Assignee: nhotta → naving
Keywords: nsbeta1, regression

Updated

17 years ago
Blocks: 141008

Comment 4

17 years ago
The folder name which are displayed as random ASCII ("mS" in the screen shot),
it shows fine as Japanse when I switch back to 7.0 PR1. So it look like this is
a display problem.
Assignee

Comment 5

17 years ago
How does it work for latin-1 folders then ?
Reporter

Comment 6

17 years ago
I first saw this on 0701 branch build.
0627 branch build does NOT show this problem. 
So it came back inbetween 0628 branch and 0701 branch.
For trunk, both 0627 trunk and 0628 trunk have the same problem.
Reporter

Comment 7

17 years ago
>How does it work for latin-1 folders then ?
As indicated in the report, Latin-1 folders work fine.

Updated

17 years ago
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt1 rtm]
Assignee

Comment 8

17 years ago
I know this has been caused by setting user given name as prettyName which we
store as PRUnichar * rather than using the disk name. I am wondering why it
works for latin-1 and not for japanese. 
Keywords: nsbeta1+nsbeta1
Whiteboard: [adt1 rtm]
Assignee

Updated

17 years ago
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt1 rtm]
Assignee

Comment 9

17 years ago
When we store this name in the db (summary file) we just do
ToNewCString(PRUnichar*) I think that causes loss in case of japanese. nhotta, how
should we convert here, perhaps to utf8 would fix it, right ?

Comment 10

17 years ago
Yes, I think so, storing as UTF-8 would not lose the data.

Comment 11

17 years ago
06/28 branch does not have the problem, it started from 06/29 branch.
Assignee

Comment 12

17 years ago
Can I have japanese, chinese names to play around with ? thx. 
Reporter

Comment 13

17 years ago
See this in Shift_JIS.
I used ねこ, a JA name.

Comment 14

17 years ago
Local folder name is dependent to default OS setting. So you need to switch the
default to test. For Japanese, you can copy/paste text from home.netscape.co.jp.
Please contact me for detail.

The problem can also be reproduced by using a symbol character. I tried a
trademark and it turned to a double-quote after the re-launch.
Here is how to type trademark on Windows.
Hold Atl key then hit numeric pad 1, 5, 3 then release Alt key.
Assignee

Comment 15

17 years ago
Posted patch proposed fixSplinter Review
I think this should fix it. nhotta, Can you try this fix w/ your testcases ?
thx.

Comment 16

17 years ago
I applied the patch to a debug build on Windows NT4 Japanese. 
It fixes the problem. I created a couple of Japanese folder names and quit,
after I re-launch the folder names are still shown correctly.

But for Japanse folders which already exist, I had to remove summary files
(.msf) to make them shown correctly. We have to do something about that because
all the exisiting non Latin1 local folder have their name stored broken in
summary files.
Assignee

Comment 17

17 years ago
yeah, that is a tricky issue. trunk builds from 6/27 onwards and branch builds
from 6/29 onwards have this problem. I don't see how we can fix it other than
just asking users to delete their msf files. 

Comment 18

17 years ago
A small # of users will have been hit by this (and no one from using a major
milestone such as 1.1, 1.0.1, or Mach V).  So, I think we can focus on fixing it
for newly created folders.

Comment 19

17 years ago
Actually the folders I created by 6.2 and PR1 cannot be shown correctly even
with the patch, I have to delete .msf files.
Assignee

Comment 20

17 years ago
Acutally all 6.x builds will have this problem because we were never converting
mailboxName to UTF8 as far as I can see. So we were storing lossyConverted char*
in the db.

I can go back and undo setting of prettyName which will fix this bug for cases
where disk names match the prettyNames (which should cover most cases). 
Assignee

Comment 21

17 years ago
Don't set the prettyName as mailboxName.
Assignee

Comment 22

17 years ago
David, Cavin, Can I get reviews for last patch ? thx. 

Comment 23

17 years ago
I removed the first patch and applied the last patch. I created a folder by PR1
and that is shown correctly without removing .msf.

One question, the pretty name change was a part of bug 153982 fix. Would
reverting it not affect the fix of bug 153982?
Assignee

Comment 24

17 years ago
No, it would not affect fix for bug 153982. It was not totally related to that
bug but it was the right thing to do because we should be storing prettyName in
case disk name doesn't match prettyName. When you create a local folder where
disk name obtained after hashing is not the same as prettyName, it will show
hash name
in the folder pane now (I think this was the same behavior before bug 153982 was
fixed).

Comment 25

17 years ago
Comment on attachment 90160 [details] [diff] [review]
proposed fix, v2

r=cavin.
Attachment #90160 - Flags: review+

Comment 26

17 years ago
Let's get an sr= on this so it can land in the trunk.  How risky is this patch?

Comment 27

17 years ago
Comment on attachment 90160 [details] [diff] [review]
proposed fix, v2

sr=bienvenu
Attachment #90160 - Flags: superreview+
Reporter

Comment 28

17 years ago
QA contact over to me.
QA Contact: marina → jeesun

Comment 29

17 years ago
Navin, can you land this on the trunk?  After it's landed, Jeesun, can you
verify this?  Navin, are there any other areas besides this actual bug that we
should test around to reduce risk?
Assignee

Comment 30

17 years ago
fixed on trunk. 

As I have mentioned before we may see the hash names instead of actual folder
names in some cases when you start-up after creating a new folder. I think we
will have to relnote this. 
Status: NEW → RESOLVED
Closed: 17 years ago
Keywords: relnote
Resolution: --- → FIXED
Reporter

Comment 31

17 years ago
Verified on 0709 trunk build
1. I created a folder using this build. After restart, it was displayed correctly.
2. I first created a folder using PR1. And it is also shown correctly in today's
trunk build.
Status: RESOLVED → VERIFIED
adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch. pls check
this into asap, then replace "mozilla1.0.1+" with "fixed1.0.1".
Blocks: 143047
Keywords: adt1.0.1+
Whiteboard: [adt1 rtm] → [adt1 rtm] [ETA 07/10]
Target Milestone: --- → mozilla1.0.1
Assignee

Updated

17 years ago
Keywords: mozilla1.0.1

Updated

17 years ago
Attachment #90160 - Flags: approval+

Comment 33

17 years ago
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.
Assignee

Comment 34

17 years ago
fixed on branch
Reporter

Comment 35

17 years ago
Verified on 0711 branch build
Keywords: verified1.0.1
Product: MailNews → Core
Product: Core → MailNews Core
Keywords: relnote
You need to log in before you can comment on or make changes to this bug.