1339815 - Request for Enhancement (RFE): if e-mail MIME body is broken, tell the user about it instead of showing a blank pane.

Status: NEW

(Thunderbird :: Message Reader UI, enhancement)

Description

[ISHIKAWA, Chiaki]

Attachment: pristine-t1.eml

I am going to upload two .eml message files.
The first one is a pristine one (with some header lines removed to protect the innocent ISP servers) that can be loaded into TB (open -> message) and we see a message with a few graphics files (it is an HTML mail file).

The second one is a slightly corrupted version of the first one.
When we load this message  into TB (open -> message), the message is shown as blank. I think this is because the corruption in the message body caused TB to fail
the parsing and deciphering MIME parts, etc. 

My request for enhancement is 
 - if the parsing fails and TB is about to show empty message pane, PLEASE SHOW an error dialog that states that TB failes to parse the message text and so the pane is empty/blank, but there is data in the message text, which may be viewable by editor.

 - This popping up of dialog should be on by default, but
   should be suppressed if a preference disable_message_body_parse_failure_popup or something similar is set to true. (Such preference should not be set in the default configuration / should not be present to start with.).
The latter is for making it easy for testing purposes in automated test.
(I found out that depending on how corrupt the message file is, TB either shows blank screen, or shows the corrupted HTML or mime data as is as a series of ASCII characters.)

In this age, it is rare we encounter such corrupt e-mails.
But when someone needs to use PPP over audio modem or something, sometimes
such error packages creep in despite the CRC check in the lower layer of protocol stack.

TIA

Comment 1

[ISHIKAWA, Chiaki]

Attachment: corrupt-t1.eml

When this file is loaded into TB, the message pane is blank.
Tested under TB 45.7.1 under Windows 10.

TIA

Comment 2

[ISHIKAWA, Chiaki]

> such error packages creep in despite the CRC check in the lower layer of protocol stack.
I meant to say such error "packets".

Comment 3

[Wayne Mery (:wsmwk)]

bug query https://mzl.la/2kxGlWq - unfortunately not very refined

Comment 4

[Jorg K (CEST = GMT+2)]

There are other bugs like this about doing things more gracefully: Bug 1274180, bug 540185.