TB detects wrong message encoding



4 years ago
2 years ago


(Reporter: denis.kostousov, Unassigned)


31 Branch

Firefox Tracking Flags

(Not tracked)



(1 attachment)

438.46 KB, application/x-zip-compressed


4 years ago
Created attachment 8532779 [details]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141113113219

Steps to reproduce:

1. I select a message in mail list
2. TB shows correct message text in mail view 
3. I open menu View -> Character Encoding and see "Western..." (don't select anythind in the menu), screenshot 1-maillist.png
4. press "forward"
5. tb opens window for forward mail editing
6. I see incorrect text in forwarded message (2-fw-incorrect-charset.png)
7. close the window then select Unicode in the character encoding menu
8. press "forward" on the message again and see correct text (3-fw-correct-charset.png)

Actual results:

tb deletect "western" charset for the message

Expected results:

tb detects unicode charset for the message
Well known case : If "charset of attached text file" != "charset of mail itself", "last charset of attached text files" is used in forward.
   message body=utf-8, attached text file=charset of Western(iso-8839-1, windows-1252, ...)
   message is shown using uft-8 as expected, but charset in mail display is changed to charset of Western of text attachment.
   So, charset of text attachment is used in forward.
This case?
If not, can you attach mail data to this bug?
  Save the mail as .eml, edit it by Text Editor which supports charset used by the mail, remove/replace personal data.

Comment 2

4 years ago
I have attached a zip with screenshot and test email message in "eml" file.

Comment 3

4 years ago
You case looks right.
(In reply to Denis Kostousov from comment #3)
> You case looks right.

Duping to bug 701818 per your comment. If different problem, re-open this bug, please.
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 701818
Duplicate of bug: 1026989
Root cause of "charset is pcked up from last attachment" was resolved by bug 1026989 at last.

Some valuable bug reports from users were hidden/lost/ignored by "duping to bug 716983, then duping bug 716983 to other bug".
Unfortunately, or fotunately, only "garbled display in Forward Inline case" was resolved by unknown bug while the other bug was being processed, so nothing was resolved by the other bug.

Duping this bug to bug 1026989, for ease of tracking, search, understanding current status of problem.
Patch of bug 1026989, one liner patch, was proposed in the other bug to which bug 716983(and bug 701818 too) had been duped to. The patch was dig out from the other bug by bug 1026989, and long lived "charset is picked up from last attachment" issue has been resolved by bug 1026989.

Why such "digging out hidden important patch from the other bug" should be needed in B.M.O?
To bug opener:
I duped this bug to bug 1026989, because your pointing out is "wrong charset(from attachment)" as known by bug summary, comment #0, instead of "garbled display in Forward Inline".

As known by bug 1026989, "Forward Inline" case was resolved by unknown bug/patch, and all other issues caused by "charset is picked up from last attchment" has been resolved by bug 1026989.
Please check with build(s) listed in the bug.
You need to log in before you can comment on or make changes to this bug.