Closed Bug 155253 Opened 22 years ago Closed 22 years ago

Forward Inline of MIME messages doesn't reflect the original charset

Categories

(MailNews Core :: Internationalization, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.0.1

People

(Reporter: marina, Assigned: nhottanscp)

References

Details

(Keywords: intl, regression, Whiteboard: [adt2 rtm])

Attachments

(3 files)

*** 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
Keywords: intl, nsbeta1, regression
OS: Windows XP → All
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).
Status: NEW → ASSIGNED
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.
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt2]
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.
Attached patch Proposed fix, v1Splinter Review
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
Attachment #90013 - Flags: review+
Comment on attachment 90013 [details] [diff] [review]
Do not set the default charset to nsIMsgWindow if forward inline or edit as new.

sr=bienvenu
Attachment #90013 - Flags: superreview+
checked in to the trunk
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
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
Blocks: 141008
Keywords: adt1.0.1
Whiteboard: [adt2] → [adt2 rtm]
The charset is now being passed to the forward window, no encoding mismatch
errors. Tested on Win2K and WinXP
Status: RESOLVED → VERIFIED
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"
Blocks: 143047
Target Milestone: --- → mozilla1.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
Attachment #90013 - Flags: approval+
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.
Attachment #90013 - Flags: approval+
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.
Attachment #90013 - Flags: approval+
checked in to 1.0.1 branch
verified the fix with 2002-07-29-1.0 build, marking as verified1.0.1
Keywords: verified1.0.1
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: