Closed Bug 119358 Opened 24 years ago Closed 24 years ago

Non-latin1 address book card is not displayed correctly after dragged and dropped to a list

Categories

(MailNews Core :: Internationalization, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.8

People

(Reporter: ji, Assigned: nhottanscp)

Details

(Keywords: regression)

*****Observed with 01/09 trunk build**** When a card with non-latin1 display name is dragged and dropped to a list, the display name of the card is not displayed correctly on the list edit window. Steps to reproduce: 1. Have a card with non-latin1 display name in your address book, like a Japanese card, or a card with a display name as "tŸst aaa". 2. Open a list, drag the non-latin1 card to the list edit window. The card is not displayed correctly, "tŸst aaa" becomes "txst aaa", the display name of a Japanese card is displayed as an ascii string. But after close and reopen the list, the cards will be displayed alright. It seems a convertion is missing when drag&drop a card to the list edit window.
It's a regression, nominating for nsbeta1.
Keywords: nsbeta1, regression
Summary: Non-latin1 address book card is not displayed correctly after dragged and dropped to a list → Non-latin1 address book card is not displayed correctly after dragged and dropped to a list
Could you test this with builds 12/21 and 12/22, to check in case this is related to the outliner change?
Status: NEW → ASSIGNED
It's working on 12/21 build, but not on 12/22 build, it looks like a regression related to outliner change.
I cannot reproduce this on my local build, the build contains a fix for bug 118010.
I think this was fixed by bug 118010.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla0.9.8
Verified as fixed with 01/14 trunk builds.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.