Int chars in Reply-To,to,cc,etc... field no decoded

VERIFIED FIXED in M18

Status

MailNews Core
Composition
P2
major
VERIFIED FIXED
18 years ago
10 years ago

People

(Reporter: Henrik Gemal, Assigned: Jean-Francois Ducarroz)

Tracking

({dataloss})

Trunk
dataloss

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [dogfood-][rtm++])

Attachments

(3 attachments)

(Reporter)

Description

18 years ago
If you have a header reply-to field in a mail like this:
Reply-to: =?ISO-8859-1?Q?Lars_H=F8jberg?= <laho@int.tele.dk>

Mozilla doesn't decode the header when you press Reply to the mail.

The To field after pressing Reply becomes:
=?ISO-8859-1?Q?Lars_H=F8jberg?= <laho@int.tele.dk>

Richard is this MIME bug yours?
(Assignee)

Comment 1

18 years ago
should be mine. Looks like I need to decode it when I extract it from the 
message headers.
Status: NEW → ASSIGNED
Target Milestone: --- → M19
(Reporter)

Comment 2

18 years ago
All other headers seems ok...
(Reporter)

Comment 3

18 years ago
Wow.. this bug has some uncool sideeffects. I have a mail with the following 
headers:
---
Reply-To: =?ISO-8859-1?Q?Lars_H=F8jberg?= <laho@int.tele.dk>
Sender: gemal@projekt.tele.dk.net
-----
If I press reply_to_all on that mail my To field will look like this:
"=?ISO-8859-1?Q?Lars_H=F8jberg?= Sender: gemal@projekt.tele.dk.net al" 
<laho@int.tele.dk>

(Assignee)

Comment 4

18 years ago
it's not only with the reply-to header but with any 8bits recipients. BAD BAD 
BAD. We must fix that for RTM. Looks like I forget to translate the recipient!!!

It's a dogfood problem as you cannot reply to 8bits recipient.
Keywords: dogfood, rtm
Priority: P3 → P2
Target Milestone: M19 → M18
(Reporter)

Comment 5

18 years ago
a header like this:
From: =?ISO-8859-1?Q?Lars_H=F8jberg?= <laho@int.tele.dk>
gives me the correct thing when using reply
(Assignee)

Comment 6

18 years ago
from is the only field which is correctly decoded. 
However, if you sent a message to yourself and to "יגה"<qwe@qwe.qwe> then try to 
do a reply-all, you will hit the problem as well.
(Assignee)

Comment 7

18 years ago
I need to decode the headers using nsMsgI18NDecodeMimePartIIStr(). SHould be a 
very safe fix.

Comment 8

18 years ago
This seems much to rare to be called dogfood, so I'm marking it dogfood-minus.
The work-around is to edit the to-field.  The worst case result is some bounced
mail resulting from some of the extra chars... but you can resend etc.
From the description of the fix, we should very likely consider this for rtm,
and the nomination is already in place.
Whiteboard: [dogfood-]
(Assignee)

Comment 9

18 years ago
momoi, is it common to have 8bits characters in a japanese email address?
(Assignee)

Comment 10

18 years ago
Created attachment 15722 [details] [diff] [review]
Proposed fix
(Assignee)

Comment 11

18 years ago
Henrik, can you test the patch (if you able able to build the project)?
(Assignee)

Updated

18 years ago
Summary: Int chars in Reply-To field no decoded → Int chars in Reply-To,to,cc,etc... field no decoded
Whiteboard: [dogfood-] → [dogfood-]Fix in hand
(Assignee)

Comment 12

18 years ago
Created attachment 15773 [details] [diff] [review]
New fix with better error handling

Comment 13

18 years ago
I applied the patch (original one), I tested the Latin1 header in the bug and
it's fixed by the patch. I also tested Japanese name in reply to, also worked fine.
For the second patch, we can use AssignWithConversion() for the error fallback.
(Assignee)

Comment 14

18 years ago
Created attachment 15779 [details] [diff] [review]
New fix, should the right way this time to handle errors
(Assignee)

Comment 15

18 years ago
cc'ing nhotta. Can you review this last version of the fix. Thanks

Comment 16

18 years ago
The latest patch looks fine, r=nhotta.
I applied the latest patch, and tried the ISO-8859-1 data and Japanese data.
Both worked fine.

Comment 17

18 years ago
*** Bug 54464 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

18 years ago
Whiteboard: [dogfood-]Fix in hand → [dogfood-]Fix in hand, reviewed & tested. Need a + now...

Comment 18

18 years ago
rtm+, corrupting 8bit headers.  Adding dataloss keyword.  You still need a super
review to get the ++.
Keywords: dataloss
Whiteboard: [dogfood-]Fix in hand, reviewed & tested. Need a + now... → [dogfood-][rtm+]Fix in hand
(Assignee)

Updated

18 years ago
Whiteboard: [dogfood-][rtm+]Fix in hand → [dogfood-][rtm+]Fix in hand, need super review
(Assignee)

Comment 19

18 years ago
sr=mscott
Whiteboard: [dogfood-][rtm+]Fix in hand, need super review → [dogfood-][rtm+]Fix in hand, reviewed and approved

Comment 20

18 years ago
PDT marking [rtm++]
Whiteboard: [dogfood-][rtm+]Fix in hand, reviewed and approved → [dogfood-][rtm++]Fix in hand, reviewed and approved
(Assignee)

Comment 21

18 years ago
Fixed and checked in Trunk & Branch
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Whiteboard: [dogfood-][rtm++]Fix in hand, reviewed and approved → [dogfood-][rtm++]

Comment 22

18 years ago
Peter, can you check this bug on the branch, thanks
QA Contact: esther → pmock

Comment 23

18 years ago
Verified as fixed on win32, linux, and macos on domestic commercial builds.
 win32 commercial seamonkey build 2000-100909-mn6 installed on P500 Win98
 linux commercial seamonkey build 2000-100909-mn6 installed on P200 RedHat 6.2
 macos commercial seamonkey build 2000-100909-mn6 installed on G3/400 OS 9.04
Status: RESOLVED → VERIFIED

Comment 24

18 years ago
Oops. need to be verified on trunck.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

Comment 25

18 years ago
Verified on branch.
Adding vtrunk to keyword.
Resolving as fixed.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Keywords: vtrunk
Resolution: --- → FIXED
(Reporter)

Comment 26

17 years ago
verifying bugs...
build 2001013020
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.