*** observed with 2002-06-28 and 07-01-1.0.0 Windows and Linux builds *** This is regression from 6.2.3 - select a message without an attachment with mime info (for ex. a 4th message in smoketest folder with UTF-8 or the one i'll attach to this report); - note that if you go to View|Encoding the charset info would be correct; - now Forward this message Inline; //note the message title doesn't reflect the charset at all, would you go now and look at the charset it'll point to the default one ( i am on EN win2k with english build so it shows Western-8859-1); //try to send the message and you'll get an error of the encoding's mismatch, after sending this message the body would displays as ??????

adding keywords, nominating because this is a regression and an important basic functionality feature

How about reply?

The reply seems to be OK.

I saw the problem on Marina's machine. But I cannot reproduce using 7/1 commercial branch (plain text and html).

I see the same problem on my english windows xp with ja locale. 1. Select the 4th msg in smoketest folder which has UTF-8 encoding. 2. Forward the msg as Inline. 3. The msg compose window's title doesn't show the charset info and ISO 8859-1 is selected in View|Character coding 4. Send and receive this. Although the body part is displayed OK (this is the only difference between Marina's and my case), the subject field has a bunch of ??? And this was sent as charset windows-1252

nsbeta1+, adt2 Please find the date of the regression.

i don't see this problem in 2002-06-24-1.0.0build, so the problem was introduced sometime between 24 and 29. Let me find out when precisely.

the problem is seen in my environement (english WInXP, english locale) with the 2002-06-25 1.0.0 build. It doesn't happen in 2002-06-24-1.0.0 build.

it looks like it's easier to see the problem in the newsgroup (go to the newsgroup, for ex. : tw.bbs.comp.linux and then repeat all steps in the bug report). You'll see that the charset for forwarding inline is not passed to the composition window. If you would cancel Send at this time and click Reply you would encounter the same problem, you would have to reload the message to get the right charset/display

On the trunk, I can see the problem starting from 06/21 build.

This is a regression by bug 137071. The charset for forward inline is set correctly after I comment out following lines. The change seems to change the loading sequence of forward inline, cc ducarroz, kaie. http://lxr.mozilla.org/seamonkey/source/mailnews/mime/src/mimedrft.cpp#278 278 //Lets cleanup the URI 279 nsCAutoString msgURI(originalMsgURI); 280 PRInt32 i = msgURI.FindChar('?'); 281 if (i != kNotFound) 282 msgURI.Truncate(i); 283 NS_UnescapeURL(msgURI); 284 pMsgComposeParams->SetOriginalMsgURI(msgURI.get());

I think the problem is in nsMsgCompose::CreateMessage. Now that we setup an original message uri for forward inline, we will potentially overwrite the charset.

A part of the problem can be also seen in 7.0 PR1 build. Using PR1, forward inline does not have the problem, but following reply does have the problem. I think the problem started to appear more frequently by the recent change of mimedrft.cpp but the basic problem has existed before that change.

This patch might fix the problem. First I have limited the scope of the fix for bug 137071 to forward inline (draft and template was affected by it). Then, I have changed nsMsgCompose::CreateMessage to not run the code that change the charset when we have an original message URI for forwardInline (previously, forwardInline message did not have a original message uri set) Naoki, can you test it...

The patch for nsMsgCompose.cpp does not compile, 'type' is not declared. + if (type == nsIMsgCompType::ForwardInline )

It was a merge problem since I got a newer version rev=1.349.

Here is a root of the problem. When we reply/forward, we remember the current charset to nsIMsgWindow so the new compose window can inherit the charset from the original message. When viewing a message, the following code is executed and set the defeault charset to nsIMsgWindow. Later in libmime when we actually detects the real charset of the message then we overwrite the default. The code below is also executed for forward as inline or edit as new. For those cases, it resets nsIMsgWindow to the default charset and unlike the view case we don't parse the header for the MIME charset. So it may overwrite the correct MIME charset. But we don't need to set the default for forward inline or edit as new in fact because it was already set when the message was shown. http://lxr.mozilla.org/seamonkey/source/mailnews/mime/src/nsStreamConverter.cpp#204 204 // notify the default to msgWindow (for the menu check mark) 205 nsCOMPtr<nsIMsgMailNewsUrl> msgurl (do_QueryInterface(aURI)); 206 if (msgurl) 207 { 208 nsCOMPtr<nsIMsgWindow> msgWindow; 209 msgurl->GetMsgWindow(getter_AddRefs(msgWindow)); 210 if (msgWindow) 211 { 212 msgWindow->SetMailCharacterSet(NS_ConvertASCIItoUCS2(*default_charset).get()); 213 msgWindow->SetCharsetOverride(*override_charset); 214 } 215 }

Comment on attachment 90013 [details] [diff] [review] Do not set the default charset to nsIMsgWindow if forward inline or edit as new. R=ducarroz

Comment on attachment 90013 [details] [diff] [review] Do not set the default charset to nsIMsgWindow if forward inline or edit as new. sr=bienvenu

checked in to the trunk

May want to get the "markings" / approval to get this into the branch.

i verified the fix in the newsgroups: the charset for Forward inline is passed to the composition window (tried several russian, chinese and japanese newsgroups). Unable to verify this fix in the smoketest folder on Local because of the bug # 155613

The charset is now being passed to the forward window, no encoding mismatch errors. Tested on Win2K and WinXP

adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch, pending Drivers' approval. pls check this in asap, then replace "mozilla1.0.1+" with "fixed1.0.1"

Comment on attachment 90013 [details] [diff] [review] Do not set the default charset to nsIMsgWindow if forward inline or edit as new. a=asa (on behalf of drivers) for checkin to 1.1

Comment on attachment 90013 [details] [diff] [review] Do not set the default charset to nsIMsgWindow if forward inline or edit as new. The patch is already on the turnk. BRANCH approval is needed.

verified with 2002-07-26-08 trunk build, the bug is fixed.

Comment on attachment 90013 [details] [diff] [review] Do not set the default charset to nsIMsgWindow if forward inline or edit as new. Approved for branch checkin. Change mozilla1.0.1+ to fixed1.0.1 when checked in.

checked in to 1.0.1 branch

verified the fix with 2002-07-29-1.0 build, marking as verified1.0.1