Closed
Bug 132613
Opened 22 years ago
Closed 22 years ago
No quoted text in reply when the original message has invalid characters
Categories
(MailNews Core :: Internationalization, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.1beta
People
(Reporter: jmdesp, Assigned: nhottanscp)
References
Details
(Keywords: intl, regression, Whiteboard: [adt2 RTM])
Attachments
(5 files, 1 obsolete file)
3.62 KB,
message/rfc822
|
Details | |
953 bytes,
message/rfc822
|
Details | |
1.00 KB,
message/rfc822
|
Details | |
910 bytes,
message/rfc822
|
Details | |
2.05 KB,
patch
|
bugzilla
:
review+
Bienvenu
:
superreview+
dbaron
:
approval+
|
Details | Diff | Splinter Review |
Checked with : Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.9+) Gecko/20020313 Has been there since a few builds, is a regression. Step for reproduction : - open a message that has some characters that are invalid in the charset that is defined inside it's Content-TYpe header - hit reply - the composition window only has "xxx wrote:" and the rest is blank. This might be a duplicate of bug 110754, but as the conditions are slightly different (invalid character for the defined Content-Type here, no Content-Type for bug 110754), I report it seperately.
Reporter | ||
Comment 1•22 years ago
|
||
Reporter | ||
Comment 2•22 years ago
|
||
Sorry I meant this could a duplicate of bug 127628. bug 110754 is a different problem. I add a reproduction of the problem in an email message, instead of a news message. This regression must be there since at least a month, but it used to work correctly before for example with Netscape 6.2.
Reporter | ||
Comment 3•22 years ago
|
||
Reporter | ||
Comment 4•22 years ago
|
||
I hope this attachment will display as utf-8 with an invalid character without
having to force the display of the browser to utf-8 as was the case with
attachment 75413 [details]. But either can be used for reproduction in mail.
Obsoletes 75413 but I don't have the rights for that.
Reporter | ||
Comment 5•22 years ago
|
||
Just like in bug 127628 , forward as inline will include the whole content of the quoted text in the reply without error. The web server still gives a default charset of ISO-8859-1 to the page with attachment 75416 [details] , but at least one can see from the start the content is not ISO-8859-1, so it's better than attachment 75413 [details].
Confirmed the bug. I can reproduce with 03/20 win32 build.
Assignee | ||
Updated•22 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.2alpha
Comment 7•22 years ago
|
||
I've just experienced this too.
Reporter | ||
Comment 8•22 years ago
|
||
I entered this bug, and forgot to check on it later. I now regret that. I figured it would be solved rapidly. This used to work and there is no reason why it should involve much change in the code to solve the problem. This problem is a bad regression that should not be there in Mozilla 1.0. Well, it will be as it's late now for that, but a correction should be planned for 1.0.x and not a future release. I know some people that will upgrade from Netscape 6.2 to Netscape 7.0, and they will encounter this as a regression from 6.2 to 7.0. bug 127628 has lead me to test and verify that this problem will also impact a chinese user with a default character coding set to EUC-TW that receive an ISO-8859-1 mail with some accentuated characters and no Content-Type header. He will not to be able to include the content of the original mail in his reply except if he manually forces it to ISO-8859-1 first. If the mail is a long message in english with only one or two accentuated characters, this will not be easy for him to discover. I couldn't reproduce when the default coding set is set to EUC-JP, despite the fact the character I used are as illegal in EUC-JP as they are in EUC-TW. With the default character coding set to ISO-2022-JP, I reproduced that problem, but this is not the standard setting for japanese users.
Reporter | ||
Comment 9•22 years ago
|
||
Problem reproduction procedure : - in Preference/Mail&Newsgroups/Message Display, set default character coding to Chinese Traditonnal (EUC-TW) - Open the attachment mail - Click on the reply button. Nothing from the initial message will be quoted in the reply.
Assignee | ||
Comment 10•22 years ago
|
||
nsbeta1 I think we want to fix this for rtm because it is not easy for the user to realize about the charset problem when encountering the blank reply. For the case of the latest attachment, the message cannot be shown correctly without explicitly setting to ISO-8859-1 by the menu. But it is possible that the user may not notice that when the messsage is long and contains not many non ASCII characters.
Comment 11•22 years ago
|
||
data lost in reply. Sounds like a very common case for mail users.
Assignee | ||
Comment 12•22 years ago
|
||
Updated•22 years ago
|
Attachment #86532 -
Flags: review+
Comment 13•22 years ago
|
||
Comment on attachment 86532 [details] [diff] [review] Added error handling for the Unicode conversion. Looks good. R=ducarroz. Just one comment, instead of: + unichars[unicharLength++] = (PRUnichar)0xFFFD; + unichars += unicharLength; I would have done: + unichars += unicharLength; + *unichars = (PRUnichar)0xFFFD; + unichars ++; That would avoid the processor to calculate twice the offset.
Reporter | ||
Comment 14•22 years ago
|
||
Wrong code, you need to do this instead to have the same result. + unichars += unicharLength++; + *unichars = (PRUnichar)0xFFFD; + unichars ++; I'm not sure it's really better after optimisation for a heavily pipelined processor. but + unichars += unicharLength; + *unichars = (PRUnichar)0xFFFD; + unichars ++; + unicharLength ++; is probably the easiest version to understand.
Assignee | ||
Comment 15•22 years ago
|
||
Also changed to use '?' instead of 0xFFFD since that character cannot be mapped by the outgoing mail charset except for UTF-8.
Attachment #86532 -
Attachment is obsolete: true
Comment 16•22 years ago
|
||
Comment on attachment 86728 [details] [diff] [review] Changed per reviewer's comment. R=ducarroz
Attachment #86728 -
Flags: review+
Comment 17•22 years ago
|
||
Comment on attachment 86728 [details] [diff] [review] Changed per reviewer's comment. sr=bienvenu
Attachment #86728 -
Flags: superreview+
Assignee | ||
Comment 19•22 years ago
|
||
checked in to the trunk
Target Milestone: mozilla1.2alpha → mozilla1.1beta
Assignee | ||
Comment 20•22 years ago
|
||
checked in to the trunk
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Updated•22 years ago
|
Keywords: adt1.0.1,
mozilla1.0.1
Comment 21•22 years ago
|
||
marina - can you pls verify this on the trunk? thanks!
Comment 22•22 years ago
|
||
can IQA verify this by this week?
Reporter | ||
Comment 23•22 years ago
|
||
Verified/fixed in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a) Gecko/20020613 I hope this goes in 1.0.1 BTW I love the new display of invalid charaters as a small question mark inside a black diamond, and no more simply as a question mark when reading. Great job. It's just simply unfortunates it has to turn to '?' in the text of the reply.
Status: RESOLVED → VERIFIED
Updated•22 years ago
|
Keywords: regression
Comment 24•22 years ago
|
||
adding adt1.0.1+. Please get drivers approval before checking in.
Comment on attachment 86728 [details] [diff] [review] Changed per reviewer's comment. Please land this on the 1.0.1 branch. Once there, remove the "mozilla1.0.1+" keyword, and add the "fixed1.0.1"
Attachment #86728 -
Flags: approval+
Keywords: mozilla1.0.1 → mozilla1.0.1+
Updated•22 years ago
|
Updated•22 years ago
|
Keywords: mozilla1.0.1+
Comment 27•22 years ago
|
||
verified on the branch, there is no data loss any more, the reply text is quoted (used the email Jean-Marc provided)
Keywords: fixed1.0.1 → verified1.0.1
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•