265393 - Changing View Layout does not preserve the mail message encoding

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[Tomasz Lisowski]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1

I am usually working in Vertical View with the Message pane turned on. The
message with the following information in the header:
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
	charset="iso-8859-2"
appeared correctly. Then I have changed the layout to Wide, and the encoding has
changed, since strange letters appeared. Toogling between all three layouts did
not change anything. So I applied the iso-8859-2 encoding again and this time
switched to the Classic layout - all was OK now.
So, switching to Classic layout is safe, whereas switching to the Wide layout
looses the encoding information.

Reproducible: Always
Steps to Reproduce:
1. Read a mail in iso-8859-2 encoding (maybe others too) in Vertical layout with
message pane turned on
2. Switch the layout to Wide
3.

Actual Results:  
The mail is displayed in the Wide layout in the wrong encoding. Changing layouts
thereafter does not help - the correct encoding must be applied again. Switching
to the Classic layout does not have this problem.

Expected Results:  
Changing layouts should not change the message encoding used to display it.

Comment 1

[Mike Cowperthwaite]

Selecting a different message and reselecting should also work to reset the 
encoding, unless you had to manually set the encoding originally.

See bug 236872 for a similar symptom.

Comment 2

[Mike Cowperthwaite]

*** Bug 273386 has been marked as a duplicate of this bug. ***

Comment 3

[Mike Cowperthwaite]

Interestingly, for Thunderbird (0.9+1201, Win2K) this is only a problem when 
switching to or from the second, "wide" layout -- switching between standard 
layout and 3-column layout doesn't appear to affect the encoding.  

Moz 1.8a6 loses the encoding for every layout switch.

Comment 4

[[e-mail]]

Switching layout should only call ReloadMessage (unless that's faulty...)

Comment 5

[Mike Cowperthwaite]

*** Bug 242918 has been marked as a duplicate of this bug. ***

Comment 6

[Mike Cowperthwaite]

Updating platform/os per dupe (reported under Linux)

Comment 7

[Tomasz Lisowski]

I just want to confirm, that this bug is still present in Thunderbird 1.0 final
(20041206)

Comment 8

[Mike Cowperthwaite]

*** Bug 280741 has been marked as a duplicate of this bug. ***

Comment 9

[Mike Cowperthwaite]

*** Bug 284983 has been marked as a duplicate of this bug. ***

Comment 10

[Mike Cowperthwaite]

*** Bug 294321 has been marked as a duplicate of this bug. ***

Comment 11

[Elmar Ludwig]

*** Bug 314394 has been marked as a duplicate of this bug. ***

Comment 12

[Elmar Ludwig]

*** Bug 319995 has been marked as a duplicate of this bug. ***

Comment 13

[Ian Hummel]

This might be similar to bug 296422.  When we switch to wide view, some widgets get reparented, you have to reload the docshell, and the call to ReloadMessages raises an exception.  This happens in thunderbird 1.5 on windows as well.

Comment 14

[Mike Cowperthwaite]

(In reply to comment #13)
> This might be similar to bug 296422.  

That's just been fixed...


> This happens in thunderbird 1.5 on windows as well.

Does it?  I can't reproduce this bug's symptom in TB 1.5 or Seamonkey 1.0, whereas it's simple to reproduce it in TB 1.0.  (With Moz 1.7, you can't 
change the layout immediately.)

Comment 15

[Mattias]

(In reply to comment #14)
This still happens with encoding iso-8859-1 in TB version 1.5 (20051201)

There are other times than when layout is switched that the encoding gets messed up.  I cannot reproduce it reliably enough though.  It happens when switching back and forth between certain folders, but not always.

Comment 16

[Mike Cowperthwaite]

(In reply to comment #15)
> (In reply to comment #14)
> This still happens with encoding iso-8859-1 in TB version 1.5 (20051201)
> 
> There are other times than when layout is switched that the encoding gets
> messed up.  I cannot reproduce it reliably enough though.  It happens when
> switching back and forth between certain folders, but not always.

What, exactly, are you saying "still happens" -- that the message encoding is lost for the displayed message when the layout is changed, or that the message encoding is lost for some other situation such as "switching back and forth between certain folders"?

It appears you mean the latter.  That is NOT THIS BUG, and so it is NOT "still happening."

You might be encountering the problem described at bug 315957.

Comment 17

[Mattias]

(In reply to comment #16)
> (In reply to comment #15)
> > (In reply to comment #14)
> > This still happens with encoding iso-8859-1 in TB version 1.5 (20051201)
> > 
> > There are other times than when layout is switched that the encoding gets
> > messed up.  I cannot reproduce it reliably enough though.  It happens when
> > switching back and forth between certain folders, but not always.
> 
> What, exactly, are you saying "still happens" -- that the message encoding is
> lost for the displayed message when the layout is changed, or that the message
> encoding is lost for some other situation such as "switching back and forth
> between certain folders"?
> 
> It appears you mean the latter.  That is NOT THIS BUG, and so it is NOT "still
> happening."
> 
> You might be encountering the problem described at bug 315957.
> 

Mike,
When I say this "still happens", I mean if I follow the instructions in the original bug description, I can reproduce the "actual result".

In addition to what the original poster describes, it also happens when switching between folders, but only sometimes.  Yes, this may be bug 315957 but I didn't know that bug existed and thought it might be relevant to this bug at the time of posting comment #15.

Win XP, TB version 1.5.0.2 (20060308)

Comment 18

[Tomer Shalev]

Happens also on the following configuration:
OS: Windows XP
Mozilla Thunderbird version 1.5.0.5 (20060719)

It seems like the problem is only with the "Wide view" layout.

Message initially appears correctly using Classic layout using Hebrew (Windows-1255) encoding.
Switching to Vertical view preserves the message's encoding.
Switching to Wide view does not preserves the message's encoding. The Encoding menu still shows the correct (Windows-1255) encoding, but selecting this encoding again redraws the message correctly. Switching back to any other layout shows the message correctly.

Comment 19

[Tomer Shalev]

Fix:
In regard to the previous comment, after switching to "Wide View" layout and losing the message's encoding, when switching back to any other view layout the message still appears incorrectly and the initial correct encoding is not preserved.

Comment 20

[Mike Cowperthwaite]

(In reply to comment #19)
> Fix:
> In regard to the previous comment, after switching to "Wide View" layout and
> losing the message's encoding, when switching back to any other view layout
> the message still appears incorrectly and the initial correct encoding is not
> preserved.

Why did you label that sentence "Fix:"?

Did you try simply selecting a different message and then reselecting the problem one, without changing layout?  That is the simple way to re-view the message correctly.


I need to retract my comment 14 & 16.  I'm not completely sure of the sequence of events, but I'm now seeing this symptom occurring in 1.5.0.5 and 2a1-0912, Win2K.

When I started retesting this today, I couldn't reproduce it.  I checked the setting for 
  View | Encoding | Autodetect
-- which, to my mild surprise, was set to Universal.  When I reset this to Off, the problem started occurring.

Normally, I run with Autodetect off, but I remember turning it on a few days ago to test something else.  I must have been in a similar situation when I was testing back in May.

Note that changing the Autodetect setting while viewing a message messes up the message appearance, but in a different way than this bug -- this symptom is bug 236872.

Comment 21

[Mike Cowperthwaite]

*** Bug 358253 has been marked as a duplicate of this bug. ***

Comment 22

[Benjamín Valero Espinosa]

I have reproduced this bug with Thunnderbird 2.0 beta 2, with the encodings ISO-8859-1 and Windows-1252 on Linux-i386.

Comment 25

[David Ascher (:davida)]

Assuming it still occurs, it should get fixed, but it doesn't sound like a blocker.

Comment 26

[Alex]

Still exists in:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b5pre) Gecko/20090503 Shredder/3.0b3pre

Comment 29

[Tim]

Still exists in:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7
(in ubuntu 10.10)

Comment 30

[Bogdancev]

User OKyJIucT reports that this bug still exists in: 
Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7

Comment 32

[Jes Carlskov]

Still exists in Thunderbird 14 beta (downloaded 2012-06-21).

The bug occurs both when switch from classic to vertical layout and vice versa.

Comment 35

[Thomas D. (:thomas8)]

Search for related bugs or duplicates (bravely assuming they mention "Layout" in bug summary):

:thun,mail [layout
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=%3Athun%2Cmail%20[layout

Comment 36

[Thomas D. (:thomas8)]

See also:

Bug 718306 - Changing layout breaks with Mail Summaries and/or Conversations
Bug 531397 - switching Layout modes breaks feed content display entirely until restart

Comment 37

[Thomas D. (:thomas8)]

Alta88 claims in Bug 531397 Comment 12 that his MoreLayoutsforThunderbird addon (1) 
fixes many bugs that occur when changing View > Layout.

Maybe he can help to fix this longstanding bug (15 duplicates since 2004), or somebody can get some coding inspiration from his addon.

(1) https://addons.mozilla.org/de/thunderbird/addon/morelayouts/

Comment 41

[alta88]

in the course of updating MoreLayouts, this (and some other layout bugs) has been fixed there:
http://morelayoutsforthunderbird.mozdev.org/

the solution is quite simple; a 0 setTimeout on the reloadMessage() call in updateMailPaneConfig will do it.

Comment 42

[Alfred Peters [:infofrommozilla]]

(In reply to alta88 from comment #41)

> the solution is quite simple; a 0 setTimeout on the reloadMessage() call in
> updateMailPaneConfig will do it.

I can confirm that it works.

Is there a reason not to do it that way?
Or why is there no patch yet?
Should I upload a one?

Comment 43

[Jorg K (CEST = GMT+2)]

(In reply to Alfred Peters III from comment #42)
> I can confirm that it works.
Then you must have a patch ;-)

> Should I upload a one?
Please do, r?alta88, then see what happens ;-)

Comment 44

[Alfred Peters [:infofrommozilla]]

Attachment: When changing layout, display the message asynchronously.

Comment 45

[Magnus Melin [:mkmelin]]

Comment on attachment 9004091 [details] [diff] [review]
When changing layout, display the message asynchronously.

Review of attachment 9004091 [details] [diff] [review]:
-----------------------------------------------------------------

::: mail/base/content/msgMail3PaneWindow.js
@@ +240,5 @@
>        messenger.setWindow(null, null);
>        messenger.setWindow(window, msgWindow);
> +      setTimeout(function DelayReloadMessage() {
> +        ReloadMessage();
> +      }, 0);

nit: no need to name the function. Also, 0 is the default so not needed.

Anyway, it may or may not fix the issue depending on your system. So a bit of a hack papering over the real problem. 
If we do take it, add a comment to explain why it's there.

Comment 46

[alta88]

(In reply to Alfred Peters III from comment #42)
> (In reply to alta88 from comment #41)
> 
> Is there a reason not to do it that way?

everyone should use the extension, how is Tb usable without wide thread view ;) which was attempted and abandoned in bug 215661.

back to the issue: although the setTimeout on ReloadMessage() works, it's not the best way and not how i do it any longer in the extension. the document in messagepane is not destroyed and therefore does not need to be reloaded/reread.  if you install the extension in Tb52 you will note how smooth and jank free the layout changes are.

to do this correctly here, try this in place of the ReloadMessage() line and make sure to test both single and multimessage (conversations):

// For some layout changes, the doc in messagepane or multimessage is
// not destroyed, so don't create it again.
let browser = getBrowser();
if (browser && browser.contentDocument &&
    browser.contentDocument.URL == "about:blank") {
  if (!gMessageDisplay.singleMessageDisplay)
    gSummaryFrameManager.pendingOrLoadedUrl = "about:blank";

  gMessageDisplay.makeInactive();
  setTimeout(() => {gFolderDisplay.makeActive();});
}

Comment 49

[Jorg K (CEST = GMT+2)]

This is not a duplicate of bug 1287336 as far as I can see. Unlike bug 1287336, this is 100% reproducible switching to another layout when a UTF-8 message is on the screen.

Comment 50

[Jorg K (CEST = GMT+2)]

Attachment: Bug265393.patch

Let's take this now to fix this annoying bug that's been around for 15 years :-( - Rebased and with comments addressed. Checked linting to avoid surprises.

Comment 51

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/11ff429ff9d1
When changing layout, reload the message via setTimeout(). r=jorgk DONTBUILD

Comment 52

[Jorg K (CEST = GMT+2)]

Comment on attachment 9118286 [details] [diff] [review]
Bug265393.patch

Will there be a TB 72 beta 3?

Comment 53

[Geoff Lankow (:darktrojan)]

72.0b3:
https://hg.mozilla.org/releases/comm-beta/rev/b4316a22736be13136f583faa6c83a563136550e

Comment 54

[Geoff Lankow (:darktrojan)]

68.4:
https://hg.mozilla.org/releases/comm-esr68/rev/3f45fb298e6800a27449ca2acb4909d42108dc5d