Compose: Need only one character coding check for both mail subject and body

RESOLVED WORKSFORME

Status

RESOLVED WORKSFORME
18 years ago
11 years ago

People

(Reporter: ji, Assigned: nhottanscp)

Tracking

({intl})

Trunk
Future
All
Windows 95

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
****observed with linux and win32 03/12 trunk build****

After a mail is composed, if the mail contains some characters not in the
specified charset, clicking on OK button can't send out mail, the character
coding warning comes up again.

Steps to reproduce:
1. Launch Mail.
2. Bring up New Msg window.
3. Enter some characters  which are not in the specified character coding, for
example, enter some Ja character in ISO-8859-1 mail.
4. Click on Send, you'll get a warning dialog. 
5. Click on OK to send the mail anyway. The mail is not sent out, the warning
comes up again. Click on OK again, this time mail can be sent out.
(Assignee)

Comment 1

18 years ago
Do not see this on my machine (win32 debug build pulled this afternoon).
Summary: Compose: Character coding warining comes up again after OK button is clicked. → Compose: Character coding warining comes up again after OK button is clicked.
(Reporter)

Comment 2

18 years ago
The warning dialog only comes up twice in case there are "illegal' characters in 
both subject and mail body. It checks subject and mail body seperately, and it 
doesn't check sender and recipient. 
(Reporter)

Comment 3

18 years ago
Filed bug 71769 for sender and recipient name.
Changed the summary to reflect the problem better.
Summary: Compose: Character coding warining comes up again after OK button is clicked. → Compose: Need only one character coding check for both mail subject and body
(Assignee)

Comment 4

18 years ago
The checks are not done in one place, instead they are done when the strings are
acutally converted. We could do the check once for all the header fields and
body before the actual conversion take place, if that not very expensive.
Currently, the maximum number of seeing the dialog is 2, I mark this as future
for now.
Status: NEW → ASSIGNED
Target Milestone: --- → Future

Updated

18 years ago
Keywords: intl

Comment 5

16 years ago
W2K, Mozilla 1.2b 2002101612

I sometimes have the warning (also with earlier builds), but it is always a
puzzle as I cannot find any illegal characters. Latest example:

I cut some text from an email, cleaned it up with ClipCache Plus
(http://www.xrayz.co.uk) in ASCII-coded text, and pasted as quotation in a new
email composition. I got the warning, and was told to change character coding to
appropriate code. No change of code seems to work, and it is all ASCII and
whatever character code I get by typing new text in text-formatted email.

I tried to reproduce it now, using the same procedure as gave me the warning,
and could not get the warning. One difference. One bug report about wrong
character code got a response to clear the cache and use Western (ISO-8859-1).
So I already cleared the memory cache before trying this test, and I have 8859-1
selected. The first time I started with 8859-15 selected, but choosing 8859-1
did not correct the problem.

Comment 6

15 years ago
This problem appears to have been fixed; I am unable to reproduce the symptom in 
Mozilla 1.6.

Comment 7

15 years ago
*** Bug 133454 has been marked as a duplicate of this bug. ***

Comment 8

15 years ago
No response from reporter; =>WFM
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.