Steps to reproduce: -open Mail; -look on the IMAP tree, - all non-ascii names look like raw 8-bit chars until you select the account again. (this bug was verified as fixed a long time ago)

reassign to selmer There are similar bugs, 35764 Regression: unable to rename non-ascii IMAP folder name 38207 Ja IMAP folder names show as utf7 strings on the folder distination menu

Scott, this looks like a totally UI thing. Can you help determine the cause?

Target nominated bugs to M16. Please update as necessary.

I don't necessarily think this is a "total" ui thing given that most of the code for this is in imap code. cc'ing jefft.

Putting on nsbeta2+ radar.

M16 has been out for a while now, these bugs target milestones need to be updated.

Is it the case that you're not connecting to the server when you open mail? In other words, is the imap account your primary account, so the inbox gets opened when you start mail, or is not your primary account?

it is a primary account and before i enter my password to get connected i see raw 8 bits.

new facts: after being connected to the server IMAP non-ascii folder name look correct but it is not the case of the non-ascii folder names on the drop-down list which you get by going Message|Copy|Move message (all non-ascii folder name still look like raw bits and it makes a folder selection impossible, you actually don't know where to file a message if you hace several non-ascii folder names)

adding alec to CC list for the menu issue.

I'll look at this.

this works for me for non-7 bit ascii characters. I don't have any folders with japanese names. Can someone point me at a test account I can use to see folders with japanese characters? I used to have one, but I seem to have lost that account.

OK, I tried this with qatest39 (sorry, but I didn't touch anything, really!), and the japanese folder names showed up fine before I entered my password. Am I missing some important steps here? 1. Add account for qatest39. 2. Open inbox, folders get discovered, including japanese folders. 3. Shutdown. 4. Restart. 5. japanese folder names show up fine.

David, now go to Message|Copy (or Move) and look on the qatest39 account tree : all non-ascii folder names are garbled

They look OK to me - I can't read the characters (i.e., I don't know if they're correct) but they don't change when I log into the server. The look the same as in the folder pane, both before and after I log into the imap server.

it is very bizarre, before i've got your comments i've crashed and restarted and now i don't see this problem.. ( i swear it was there the whole morning ..)Let me see what is the reproducable scenario again..

spooky :-) I can't think of any reason that crashing should affect this. I can imagine that if you had an old profile with bad information in panacea.dat (from months ago?), that you might see this bug. But starting with a new or migrated profile should be OK.

I can't see the image - I get a broken image. If I could see it, would it mean that you were able to reproduce the problem?

You're right about migrated profile and i can not start today with a new one (crash). I was working with an old profile(like three days old...)

a three days old profile should be fine - the bug I was thinking about is from several months ago.

marina, when you make attachments you have to attach the jpeg file, not the HTML file that encloses it. (try view source on the file you just attached, you'll see that you actually attached an HTML file)

I saw this problem again with the following scenario on today's linux build: 1. Create a new profile. 2. Start mail with the new profile, you'll have to go through account setup wizzard to connect to an IMAP account, I didn't provide the password when setting up the account. 3. Get the password window and the folder tree on the left only shows INBOX under the account, enter correct passsword, all the folders will be listed correctly. This time, you won't see the raw utf7 string for non-ASCII folders. 4. Exit the application. 5. start application again using ./netscape -profilemanager & 6. Select the new created profile and start the application. 7. Select Tasks | Mail from browser window. This time the folder tree will be listed on the left and non-ascii folder name shows as raw utf7 string. 8. If you exit the application and lauch browser and mail again, you won't see the problem.

now a reproducable scenario: -launch messenger with an existing profile (created yesterday) -create an IMAP account(qatest39 on nsmail-5); -enter password to access Inbox; - select a message; - go Message|Copy File (get a drop-down list of folders) //note: folder names look like raw bits

since this is an nsbeta2+ bug I'm just curious about the severity of this bug as I try to find bugs to cut. It sounds like this only happens the first time you run. Once you've logged in, is it true that this problem goes away? If it is, then I think this is something we could release note and remove from the beta 2 list.

I'd say it's release-note-able, especially since I can't reproduce it.

I'm removing the nsbeta2+ and asking for consideration to not do this for beta2.

Putting on [nsbeta2-] radar. Not critical to beta2.

adding nsbeta3 keyword

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

Mail triage is marking nsbeta3-

Is this really worth relnoting? It's only cosmetic, and temporary AFAICS... The blurb: It seems unclear to me whether this bug requires either of a "developer" or "user" release note for Netscape 6 RTM. If anyone feels it does, can they please draft one and then nominate with the relnote-user or relnote-devel strings in the Status Whiteboard. Thanks :-) Gerv

I don't think it's worth relnoting

changing priorities

marina, please update the status of this bug since we haven't looked at this for a while.

marking nsbeta1- as per I18N triage.

Mass change to bugs filed by marina --> QA contact to marina. thanks!

Marina - Is this still an open issue? What's the user impact here?

i don't see it happening in the non-ascii folder create case but it is happening in the rename non-ascii folder scenario (bug #35764). The impact is that if you don't restart the messenger you'll see raw bits after renaming the folder to a non-ascii name :1. cosmetic and 2. when Move/Copy message you don't see the destination folder correctly so you are not sure where to move/copy message

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.

cleaning up nsbranch keywords.

getting nsbranch- back; I want to keep track of bugs that people nominated and were latered. This will help us for a first round of bug in the next release

Removing nsbeta3.

nomianting as a regression.

I don't see this anymore with the latest builds. Marina, do you still see this?

i was seeing it quite recently with Web mail account but not in the currecnt build, i am marking it as WFM, would i notice something wrong with the display i'll reopen

verifying