Changing View Layout does not preserve the mail message encoding

RESOLVED DUPLICATE of bug 1287336

Status

--
minor
RESOLVED DUPLICATE of bug 1287336
15 years ago
4 months ago

People

(Reporter: tlis, Unassigned)

Tracking

Bug Flags:
blocking-thunderbird3 -
wanted-thunderbird3 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
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

15 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

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

Comment 3

15 years ago
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.
OS: Windows XP → Windows 2000
Switching layout should only call ReloadMessage (unless that's faulty...)

Comment 5

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

Comment 6

14 years ago
Updating platform/os per dupe (reported under Linux)
OS: Windows 2000 → All
Hardware: PC → All
(Reporter)

Comment 7

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

Comment 8

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

Comment 9

14 years ago
*** Bug 284983 has been marked as a duplicate of this bug. ***
*** Bug 294321 has been marked as a duplicate of this bug. ***

Comment 11

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

Comment 12

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

Comment 13

13 years ago
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.
(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

13 years ago
(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.
(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.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME

Comment 17

13 years ago
(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)

Updated

13 years ago
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Comment 18

13 years ago
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

13 years ago
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.
(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.
*** Bug 358253 has been marked as a duplicate of this bug. ***
I have reproduced this bug with Thunnderbird 2.0 beta 2, with the encodings ISO-8859-1 and Windows-1252 on Linux-i386.
Duplicate of this bug: 377183
QA Contact: front-end
Duplicate of this bug: 392643

Updated

11 years ago
Flags: blocking-thunderbird3?
Assuming it still occurs, it should get fixed, but it doesn't sound like a blocker.
Assignee: mscott → nobody
Status: REOPENED → NEW
Flags: wanted-thunderbird3+
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3-

Comment 26

10 years ago
Still exists in:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b5pre) Gecko/20090503 Shredder/3.0b3pre
Version: unspecified → Trunk
Duplicate of this bug: 494264
Duplicate of this bug: 569233

Comment 29

8 years ago
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

8 years ago
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
Duplicate of this bug: 654406

Comment 32

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

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

Updated

7 years ago
Duplicate of this bug: 520953

Updated

7 years ago
Duplicate of this bug: 767031

Comment 35

7 years ago
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

7 years ago
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

7 years ago
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/
Duplicate of this bug: 1120597
Duplicate of this bug: 1128148

Updated

4 years ago
Duplicate of this bug: 876532

Comment 41

4 years ago
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

7 months ago
(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?

Updated

7 months ago
Flags: needinfo?(alta88)

Comment 43

7 months ago
(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 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

7 months ago
(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();});
}
Flags: needinfo?(alta88)

Updated

7 months ago
Attachment #9004091 - Flags: review?(alta88)

Updated

5 months ago
Status: NEW → RESOLVED
Last Resolved: 13 years ago5 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1287336

Updated

4 months ago
Duplicate of this bug: 1509812
You need to log in before you can comment on or make changes to this bug.