315957 - Wrong characters displayed/encoding (and more) when viewing message for the first time

Status: RESOLVED DUPLICATE of bug 1287336

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051109 SeaMonkey/1.5a] (nightly) (W98SE)

Since a couple of weeks (but I may not actually remember),
I get the same kind of display as in (TB) bug 314394 attachments.

I'm using Classic Layout with Message and Folder pane,
and never changing it.

This happens (often but not always !?) when first displaying the message:
workaround is to display another message and then display the first one again.

I have not true verified this yet, but I may have two hints:
1) Once, I had the message pane closed, I display a message in a new window, the display was fine, I closed the window, added the message pane (F8), and got this bug.
2) This bug happened with a message which got 3 attachments ... when it showed the bug on first display, the attachement list was double: 1, 2, 3, 1, 2, 3; on redisplay, the bug did not show up and the list was unique too.

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.12) Gecko/20050915] (release) (W98SE)

I'm almost sure I never got that in Mv1.7.

Moreover, I have the feeling that first retrieving and displaying a message in Mv1.7 makes the bug not show up on it if using SMv1.5a thereafter !? (that would need confirmation)

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20051107 SeaMonkey/1.0b] (release) (W98SE)

I think SMv1.0b branch may have this bug too ... but I'm not sure enough yet: simple reminder for me to check later.

Comment 1

[Mike Cowperthwaite]

IMAP or POP?

Comment 2

[Serge Gautherie (:sgautherie)]

IMAP for sure.
(POP, I would have to check.)

Comment 3

[Serge Gautherie (:sgautherie)]

(In reply to comment #2)
> IMAP for sure.

I switched temporarily to another profile,
and got this bug on a POP account too.

Comment 4

[Serge Gautherie (:sgautherie)]

(In reply to comment #0)
> [Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20051107 SeaMonkey/1.0b]
> (release) (W98SE)

(For the record, that build was a nightly :->)

Comment 5

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060115 SeaMonkey/1.5a] (nightly) (W98SE)

I seems that I have found a way to reproduce this bug:
This bug happens when I
1) Use F8 to hide the message pane
2) Select a message different from that last one that was displayed
3) Use F8 to show the message pane

3a) First display of that newly selected message is incorrect

Comment 6

[Mike Cowperthwaite]

(In reply to comment #5)
> I seems that I have found a way to reproduce this bug:
> This bug happens when I
> 1) Use F8 to hide the message pane
> 2) Select a message different from that last one that was displayed
> 3) Use F8 to show the message pane
> 
> 3a) First display of that newly selected message is incorrect

What are the character encodings of the respective messages?  Are you using AutoDetect?

Comment 7

[Serge Gautherie (:sgautherie)]

(In reply to comment #6)
> What are the character encodings of the respective messages?  Are you using
> AutoDetect?

For example:
*Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
*Content-Type: text/html;charset=iso-8859-1;

No (Asian) AutoDetect:
It's set to Western (ISO-8859-1).

Comment 8

[Mike Cowperthwaite]

(In reply to comment #7)
> No (Asian) AutoDetect:
> It's set to Western (ISO-8859-1).

So you do have AutoDetect turned on?  Do you get the same results if you 
turn it off?

Is the default encoding for the folder also set to 8859-1?

Comment 9

[Serge Gautherie (:sgautherie)]

(In reply to comment #8)
> (In reply to comment #7)
> > No (Asian) AutoDetect:
> > It's set to Western (ISO-8859-1).
> 
> So you do have AutoDetect turned on?  Do you get the same results if you 
> turn it off?

It is turned Off: it's set to 'Western (ISO-8859-1)'.

> Is the default encoding for the folder also set to 8859-1?

Yes.

Comment 10

[Serge Gautherie (:sgautherie)]

Sometime ago, I tried to reproduce this bug on SMv1.0b on WinXP, but it behaved fine.
(Yet another bug that could be on my home computer only :-/)

Comment 11

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.0.2) Gecko/20060404 SeaMonkey/1.0.1] (nightly) (W98SE)

SMv1.0 works fine.

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20060411 SeaMonkey/1.1a] (nightly) (W98SE)
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060403 SeaMonkey/1.5a] (nightly) (W98SE)

SMv1.1a (and Trunk) has this bug.

I'll try to narrow down the timeframe on the MOZILLA_1_8_BRANCH...

Comment 12

[Serge Gautherie (:sgautherie)]

(In reply to comment #11)
> I'll try to narrow down the timeframe on the MOZILLA_1_8_BRANCH...

(unlucky to have tried so many builds, lucky not to have search soonner :-|)

Good
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20051227 SeaMonkey/1.0b
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20060215 SeaMonkey/1.1a
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20060315 SeaMonkey/1.1a
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20060401 SeaMonkey/1.1a
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20060406 SeaMonkey/1.1a
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20060408 SeaMonkey/1.1a

Bad
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20060409 SeaMonkey/1.1a
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20060410 SeaMonkey/1.1a

Comment 13

[Serge Gautherie (:sgautherie)]

As the following patch was checked in on
2006-04-08 15:45	bugzilla%arlen.demon.co.uk 	mozilla/mailnews/base/resources/content/widgetglue.js 	1.171.12.1 	MOZILLA_1_8_0_BRANCH
too

2006-04-08 15:43	bugzilla%arlen.demon.co.uk 	mozilla/mailnews/base/resources/content/mail3PaneWindowVertLayout.xul 	1.106.2.4 	MOZILLA_1_8_BRANCH  	2/2  	Bug 121176 Turn off title setting when the message pane is collapsed p=neil r=dmose/mnyromyr sr=dmose a=kairo for SM1.1a on behalf of SeaMonkey Council (SM only patch)

this bug must be "caused" by

2006-04-08 10:13	jshin%mailaps.org 	mozilla/toolkit/xre/nsXREDirProvider.cpp 	1.37.2.4 	MOZILLA_1_8_BRANCH  	16/0  	bug 162361: Unicode file i/o in XPCOM/IO (cannot open files whose names contain characters outside the current locale: e.g. Japanese/Chinese on French Windows) : r=bsemdberg, sr=darin, a1.8=darin)

Comment 14

[Serge Gautherie (:sgautherie)]

[Mozilla Thunderbird, version 3 alpha 1 (20060403)] (nightly) (W98SE)

TBv3.0a1 doesn't seem to have this bug.
(but I didn't check my profile' configuration.)

Comment 15

[[e-mail]]

I'd say bug 121176 is suspicious. Can you try unpatching your chrome files?

Comment 16

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20060502 SeaMonkey/1.1a] (nightly) (W98SE)

Commenting out the following line in <commandglue.js> is enough to fix the regression:
[[
function ChangeMessagePaneVisibility(now_hidden)
{
  // we also have to hide the File/Attachments menuitem
  var node = document.getElementById("fileAttachmentMenu");
  if (node)
    node.hidden = now_hidden;

  if (gDBView) {
    // clear the subject, collapsing won't automatically do this
    setTitleFromFolder(GetThreadPaneFolder(), null);
    // the collapsed state is the state after we released the mouse 
    // so we take it as it is
    gDBView.suppressMsgDisplay = now_hidden;
    // set the subject, uncollapsing won't automatically do this
//    gDBView.loadMessageByUrl("about:blank");
    gDBView.selectionChanged();
  }
]]

I guess the triggering factor is that <about:blank> is an "UTF-8" page !?

NB: I searched for similar bugs once, and I found an issue about "reparenting", but I don't know if it applies in this case.

Comment 17

[Serge Gautherie (:sgautherie)]

(In reply to comment #13)

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.0.4) Gecko/20060502 SeaMonkey/1.0.1] (nightly) (W98SE)

I had tested with a build which was older than the checkin for bug 12176 :-<
SMv1.0.x branch does have this bug too (now).

Comment 18

[Simon Montagu :smontagu]

The cause of the regression is similar to bug 315381, but it seems from comment 16 that the patch there doesn't fix it.

Comment 19

[Serge Gautherie (:sgautherie)]

(In reply to comment #18)
> The cause of the regression is similar to bug 315381, but it seems from comment
> 16 that the patch there doesn't fix it.

Yes, that's the "reparenting" bug which I was thinking of :-)
My comment 16 here applies to SMv1.1a ... I'll check again after 1.8.1 branch landing of patch for bug 315381.

Comment 20

[Robert Kaiser]

Looks like noone working on this and only happening in some cases, so not blocking 1.0.2 on it or we can't release it in time.
Note that we'd really like to see a regression fix, but as long as we do not, we need to make sure we still can ship security updates.

Comment 21

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1a2) Gecko/20060516 SeaMonkey/1.1a] (nightly) (W98SE)
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1a2) Gecko/20060517 SeaMonkey/1.1a] (nightly) (W98SE)

I tested both nighlies since bug 315381 was checked in to the 1.8.1 branch,
and I confirm that it does not fix this bug :-(

Neil: helpwanted :->

Comment 22

[[e-mail]]

(In reply to comment #21)
>Neil: helpwanted :->
Well, going by comment 16, maybe we should back out bug 121176.

Comment 23

[Serge Gautherie (:sgautherie)]

Am I the only one to see this regression ?

If reverting, would removing the line identified in comment 16 be enough (the title seems to update fine still), or should it be the whole patch ?

Comment 24

[[e-mail]]

(In reply to comment #23)
>the title seems to update fine still
Just to check:
1. hide preview
2. select a message
3. show and hide preview, ensure title updates then clears
4. show and hide preview, ensure title updates then clears
5. select a message
6. show and hide preview, ensure title updates then clears
7. show and hide preview, ensure title updates then clears

Comment 25

[Serge Gautherie (:sgautherie)]

(In reply to comment #24)
> (In reply to comment #23)
> >the title seems to update fine still
> Just to check:

Removing the one line:
*The "UTF-8" bug disappears at steps 3 & 6 :-)
*The title doesn't update at steps 4 & 7 :-(

*** I made another test, which could be +/- related:

While the message pane is visible,
if I (ctrl-)select a second message,
the title clears, and the header and message pane disappears/clears too.
(fine)

Then, if I hide and unhide the message pane,
while the message body stays blank,
the title updates and the header pane reappears (with the topmost selected message data).
(this looks like a bug too, doesn't it ?)

Then, with the one line removal,
the message body reappears too :-(

*** Now, I don't know how to properly fix any of theses two bugs.

I also checked
[Mozilla Thunderbird, version 2 alpha 1 (20060517)] (nightly) (W98SE)

a) The window/folder title never updates to the message title.
b) In case of multiple selection, it behaves like SeaMonkey with the one line removal: always shows the message body after unhiding.

No help from there :-<
(but 1.8.1 branch TB does not have the current bug.)

Comment 26

[Robert Kaiser]

Same situation as in comment 20 is still true. We seemingly have one single user who sees this, not sure if other developers can reproduce, we have shipped a few releases with this without anyone (else) complaining, and no active work happening here apparently.
Still, it would be nice to see a fix, but not going to block a release for it.

Comment 27

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.2pre) Gecko/20070108 SeaMonkey/1.1] (nightly) (W2Ksp4)

Confirming bug on my new W2K.
(Could be my profile (which I kept), or using an en-US SeaMonkey on a fr Windows !?)

Comment 28

[Mike Cowperthwaite]

Serge, see bug 333830 -- do you have "Remember Last Message In Folder" set?  If you turn that off, does that affect the symptom(s) of this bug?

Comment 29

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a2pre) Gecko/20070128 SeaMonkey/1.5a] (nightly) (W2Ksp4)

Yes, bug 333830 is yet another bug with the same visual symptom as this one.
(Reminder: from comment 0 here, bug 314394 is R.Duplicate, to bug 265393 which is still "Reopened".)

No, unsetting the "Mail & Newsgroups > Remember the last selected message" pref. does not workaround this bug.
(I tried changing folder, even restarting.)

Comment 30

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a9pre) Gecko/2007101002 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

I'm still seeing this bug (using F8),
with new Toolkit SeaMonkey ... with new (= non migrated) profile.

Comment 31

[Tony Mechelynck [:tonymec]]

I have occasionally (and much more recently than 2007) seen email messages which were garbled on first read. Hitting F5 ("Reload") often fixed it, and replying to the "apparently garbled" message displayed the text "un-garbled" in the Message Compose window, proving that these particular messages (at least) had the charset correctly set in their headers.

Comment 32

[Tony Mechelynck [:tonymec]]

P.S. Happened to me a few seconds ago for a message from Usenet newsgroup soc.culture.esperanto. F5 fixed it.

Comment 34

[Tony Mechelynck [:tonymec]]

This bug is not a very severe bug, certainly not a blocker, but it is annoying to those who see it, including (but not limited to) Serge and me. It has been seen since shortly before the Toolkit Transition, and is still extant. I'm asking for "tracking" status, hoping to avoid seeing it fall off the radar.

Comment 36

[bblack]

Sorry wrong bug number