Closed Bug 138008 Opened 22 years ago Closed 14 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: 14 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: