Created attachment 8602700 [details] EML file showing the problem Import the attached messages and hit "Reply All". What you get is a really badly formed to address. As far as I can see, the message is not even malformed, the header: To: =?iso-8859-1?Q?Hans-Joachim_Wollschl=E4ger_=28hj=2Ewollschlaeger=40t-onli?= =?iso-8859-1?Q?ne=2Ede=29?= <email@example.com> is legal and is also decoded successfully and displayed correctly in the message header display in the message pane. The resulting address is: "=?UTF-8?Q?Hans-Joachim_Wollschlfirstname.lastname@example.org=29?=hj.wollschlaeger"@t-online.de I think we have a problem if users can't reply to e-mail. I sent the message out without noticing.
Sorry Kent, another one you won't like for your kind attention. Looks a bit like bug 1130248, only that there are no quotes in the header. The mangling is just the same as in the other bug. Perhaps not a jsmime problem at all but a problem in the interface between jsmime and message compose window, refer to bug 1130248 comment #7.
I'm sure Neil can help us here ;-)
Regression: works OK in 31.6
Thanks jorg for the clear example, I'll be looking at this.
According to my tests, I can see this bug in beta 4, but I do not see it when bug 1141446 is landed, as it will be in beta 5. So I believe this is just a duplicate of bug 1141446. Jorg can you confirm this? (On another note, I changed the address that I use for BMO from email@example.com to firstname.lastname@example.org so that the short form of my name would match my handle. Please do not cc email@example.com, use firstname.lastname@example.org instead.)
(In reply to Kent James (:rkent) from comment #5) > According to my tests, I can see this bug in beta 4, but I do not see it > when bug 1141446 is landed, as it will be in beta 5. So I believe this is > just a duplicate of bug 1141446. Jorg can you confirm this? I cannot confirm this. I made the change that was made for bug 1141446 in my local build, and the bug is still there. The change for bug 1141446 was rfc2047-decoding all quoted strings. The header in question: To: =?iso-8859-1?Q?Hans-Joachim_Wollschl=E4ger_=28hj=2Ewollschlaeger=40t-onli?= =?iso-8859-1?Q?ne=2Ede=29?= <email@example.com> has no quotes, so the fix from bug 1141446 doesn't apply. However, another change to jsmime was landed, bug 1069790. That was far more than a one line change, perhaps that fixed it. Bug 1069790 was landed after beta4, so that is more likely to have fixed it. Reading bug 1069790 again: That must be it, since it had to do with parenthesis and the decoded header is: Hans-Joachim Wollschläger (firstname.lastname@example.org) <email@example.com>
Something fishy here, Kent. I tried in a recent build with the bug 1141446 fix included. Still getting: "Hans-Joachim Wollschläger (firstname.lastname@example.org)hj.wollschlaeger"@t-online.de You claim it's fixed and you also claim bug 1130248 is fixed which I also cannot confirm. So what have you got that I don't have? Note: trunk and beta are almost the same at the moment, only difference being http://hg.mozilla.org/comm-central/diff/1cf79e3da57a/mailnews/mime/jsmime/jsmime.js So for all intents and purposes, they should behave the same. However, I'm not even sure this is a jsmime problen. Perhaps it got silently fixed some other way.
Refreshed local build: $ hg pull -u ... (can't do python client.py checkout due to bug 777770) added 10 changesets with 13 changes to 10 files (+1 heads) Problem persists in locally compiled version.
Ask for help again.
Sorry, my local build had a problem (I've cleaned it out now "hg up --clean -r default") but I still need to get TB to build, which is a pain due to bug 777770). So perhaps I gave you the wrong answer and you are right that it's fixed. To be continued in a few hours when I can check it again.
With M-C a rev 617dbce26726 (due to bug 777770) and C-C at rev d3090583a3cb (due to compile problems after landing bug 1163331) I observe the following: The problem persists, recipient still: "Hans-Joachim Wollschläger (email@example.com)hj.wollschlaeger"@t-online.de Kent: I think you owe me one for the wild-goose chase you sent me on.
Let's not confuse bug 1162477 and bug 1130248: To reproduce this bug 1162477 do "Reply" all, for bug 1130248 do "Compose Message To". The other way around it all works.
Karsten, you worked on bug 1069790, could you help with this one?
OK the nature of the problem changed from comment 0 in beta 4, but as you noted in comment 11 it was still incorrect. But at the risk of being wrong again, I no longer see the issue with my patch from bug 1130248 applied. The bugs are similar, but in this bug the address is buried in a comment inside of RFC 2047 encoding. I believe that the previous code correctly handled an address inside of a comment (or at least that is included in one of the tests) without RFC 2047 encoding, so it must be the combination of comment-in-address with RFC 2047 that was confusing. So I'm not exactly sure it is a duplicate, but unless you can show me another problem I won't block on this, at least given that we are blocking on bug 1130248.
I suspected it had to do with bug 1130248. So most likely you've hit two birds with one stone.
With the patch from bug 1130248 this cannot be reproduced. I applied the patch, problem went away, then I popped the patch, problem returned. However, as stated in the other bug: The patch is suboptimal. Besides, I'd like to see an explanation why the patch fixes this problem too. "Works by accident" is possibly not a good solution.
Sorry for my silly hasty comment #16. I can see now that this is a duplicate of bug 1130248 and how the patch fixes it. The common element is the e-mail address in the name part.