Closed Bug 138008 Opened 23 years ago Closed 15 years ago

Non-ascii HTML signature file doesn't work

Categories

(MailNews Core :: Internationalization, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 201071

People

(Reporter: jeesun, Assigned: nhottanscp)

References

Details

(Keywords: intl, Whiteboard: [need info])

Attachments

(1 file)

Non-ascii signature file doesn't work BuildID: 2002041505 - 1.0.0 Branch build on Mac OSX Steps: 1. Open Mail 2. Go to Edit>Mail & News Account Settings 3. Select any mail account 4. Check the box for "Attach this signature" and enter the path to a signature file with a non-ascii name and non-ascii content. Then click OK. Result: 1. Click on "Compose button". The content of signature file are NOT displayed in the body of message compose window. 2. Go back to Edit>Mail & News Account Settings, the path to the signature file get erased. Expected: 1. A path to non ascii signature file should be displayed correctly all the time 2. Non ascii content of signature file should be displayed in the compose window. Note: 1. I tried both latin-1 and Hiragana/Katakana. Neither of them worked. 2. If you use a signature file with ascii name, it works 3. This was observed on Mac OSX. I haven't tried Windows yet
>4. Check the box for "Attach this signature" and enter the path to a signature >file with a non-ascii name and non-ascii content. Then click OK. Could you separate the test case into two, one with non ascii file name the other with non ascii content?
Status: NEW → ASSIGNED
Let me back off and rephrase the whole thing. 1. System locale set to English 2. System locale set to Japanese The original bug description applies to #1 for which I'll add more comment later. Regarding #2 (Japanese system locale), this is what I've observed. I tried: A. Signature file with Japanese file name AND Japanese content B. Signature file with English file name AND Japanese content For both A and B, I am able to see a path to signature file correctly all the time in Edit|Mail & News Account Settings window. However, when I click on Compose button, in compose windows, the non-ascii content of signature file looks garbled. The default encoding for message composition and display is ISO-2022-JP. I'll attach the screenshot later (now, I don't know how to this on Mac)
With the system locale set to Enlgish (#1 case above), A. Signature file with Japanese file name AND Japanese content B. Signature file with English file name AND Japanese content Case A shows the same problem which I originally mentioned. (1. Click on "Compose button". The content of signature file are NOT displayed in the body of message compose window. 2. Go back to Edit>Mail & News Account Settings, the path to the signature file get erased or shows the previous English file) Case B does NOT show this kind of problem. But in Compose windows, the content looks garbled. (Just like what I observed on system with Japanese locale)
<Case A shows the same problem which I originally mentioned. <(1. Click on "Compose button". The content of signature file are NOT displayed <in the body of message compose window. the signature file with .rtf extension doesn't work for ascii name neither. html though works fine for both. cc'ing to core qa. Is there a bug for plain text signature on MacOSX? Thanks.
QA Contact: ji → jeesun
Naoki, is this a dup of bug 52248 ? bug 52248 only mentions unix plaform.
*** Bug 156964 has been marked as a duplicate of this bug. ***
>Naoki, is this a dup of bug 52248 ? bug 52248 only mentions unix plaform. It looks different. "Non-ascii signature file doesn't work" There are two types of signatrue, HTML and plain text. Which case is this bug about?
Keywords: intl
I tried HTML signature file. Revised steps: (on both windows and macosx with JA system locale) 1. Using a browser's composer, create JA HTML signature file and set encoding to ISO-2022-JP 2. Set this file as you signature file in Edit|Mail and Newsgroup account settings. 3. Click on Compose button. Make sure your default encoding for viewing and composing msg is set to ISO-2022-JP 4. Your signature looks weird 5. Compose and send a msg to yourself. 6. In the received msg, the signature looks OK. Note: In step 1 above, if you use Shift_JIS when creating a signature file, it looks OK in compose window.
Summary: Non-ascii signature file doesn't work → Non-ascii HTML signature file doesn't work
It also happens with plain text signatures (ISO-8859-1 with german umlauts)
>It also happens with plain text signatures (ISO-8859-1 with german umlauts) Please specify your environment (OS, default locale and Mozilla build info).
Since this happens both on mac and windows, I'm changing platform and os info.
OS: MacOS X → All
Hardware: Macintosh → All
I have seen it on Linux with de_DE@euro (ISO-8859-15) locale.
nominating....
Keywords: nsbeta1
Naoki, I think this bug needs more attention. Since ISO-2022-JP is most frequently used as an encoding method for our mail,we'd better support signature file with the same encoding. Now, signature file with ISO-2022-JP encoding looks garbled in the compose window.
changing qa contact
QA Contact: jeesun → marina
Still reproducible on 1217 trunk build.
i18n triage team: need info. Marina to test this.
Whiteboard: [need info]
adt: nsbeta1-
Keywords: nsbeta1nsbeta1-
Cannot get swedish characters 8859-10 in signature file to come up correctly when composing new message. Have tried most everything. /Carl Stenquist
Product: MailNews → Core
In the wake of the fix for bug 201071 (current 1.8.1 branch and trunk), I'm wondering about this bug's status. With that fix, a sig (for plain text or HTML) will be recognized if it's encoded either in the system default encoding, or in UTF-8. This should be true for all platforms. See bug 362675, which seems to reflect directly on comment 21 (assuming Mr Stenqvist is using Windows).
Product: Core → MailNews Core
QA Contact: marina → i18n
Not reproduce on Thunderbird 3.1. We should dup of bug 201071
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: