430697 - Forwarding of messages using Content-Disposition: Inline fails

Status: NEW

(Thunderbird :: Message Compose Window, defect)

Description

[Harrison Neal]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; InfoPath.1; .NET CLR 3.0.04506.648)
Build Identifier: version 2.0.0.12 (20080213)

I've received several e-mails produced by Novell GroupWise that embedded HTML content in the following manner:

Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
Content-Disposition: inline;

If such an e-mail is opened in Outlook Express, the client displays the HTML content lnline and also correctly forwards the content inline as well.

In Thunderbird, if Tools>Options>Composition>General>Forward Messages is set to Inline, and a message in the format described above is opened, Thunderbird correctly displays the HTML content inline, but it does not forward the content inline.

Reproducible: Always

Steps to Reproduce:
1. Receive an e-mail with HTML content included as base64 encoded inline content.
2. Set Tools>Options>Composition>General>Forward Messages to Inline.
3. Attempt to Forward the E-Mail.
Actual Results:  
Thunderbird does not copy the inline content into the new composition window. Apart from a user signature if applicable, the new mail composition window is blank.

Expected Results:  
The HTML inline content should be correctly and fully copied into the new mail composition window.

Comment 1

[rsx11m]

Could you either attach a test case (such a message saved as EML file with any information disguised that you don't want to post publicly) or provide some more information about the structure of the message?

It would be good to see all message parts, i.e., all Content-* headers for the individual parts along with the level of nesting based on the boundary markers.

Comment 2

[Harrison Neal]

Attachment: Example of Message not properly forwarded (compressed due to size constraints).

Comment 3

[rsx11m]

I did some testing with your message, and it should prompt both bug 307023 (based on MIME-type nesting and encoding of the HTML part) as well as
bug 296282 (based on base64+inline HTML encoding). I can reproduce your observations on the current trunk nightly build [Thunderbird 3.0a2pre (Windows/2008051503)]. Forwarding inline, editing as new, and replying all
give me an empty message, not even the table with the headers shows up when forwarding. This is independent from the View > Message Body As setting and
the composition mode (plain or HTML text).

Now, the big "however", I see a different behavior on branch [TB 2.0.0.14 (Windows/20080421), SM 1.1.9 (Linux/20080410)]. Replies work in both HTML and plain-text composition modes when viewed as Simple or Original HTML, including the images for HTML composition. I get a blank quote ("<author> wrote:" only) when replying from Plain Text view, which is irritating as a plain-text alternative part is present in the original message. Forwarding inline and editing as new show the behavior described in bug 296282, an arbitrary short string shows up instead of the original message, no images. The header table is present though, and this is independent from the message-display mode.

What is confusing to me is that you report the behavior which I see in the current 3.0a builds for the 2.0.0.12 release, where I see a different behavior more consistent with prior bug reports. In any case, I agree that something is wrong and apparently different here, either caused as a variant of bug 296282, bug 307023, or bug 394322, or something else hidden in the HTML encoding itself.

Comment 4

[rsx11m]

Attachment: Decoded HTML part of that message

...in case someone wants to have a look at the HTML encoding of this message, if it is in compliance or has any weirdnesses which could explain this behavior. Definitely a lot of MSO-tags in there.

Comment 6

[rsx11m]

Confirming this based on test cases provided here as well as in bug 434992.
This appears to be related to one of the bugs cited in comment #3 but nevertheless looks different.

Only confirming for Windows as I could not reproduce this on Linux, and
also not on SeaMonkey (this may be a Core bug though).

Comment 7

[Shane Shields]

Attachment: shows mail forwarding problem on linux and windows

With this attachment forwarding the message as either simple html or original html shows no mail body. Replying to the message does show the body.

Comment 8

[Shane Shields]

As in the comment added with my previous attachment this problem is with both Linux and Windows TB. It also shows the same symptoms as bug 337576 which I think is a duplicate. The Linux version is version 2.0.0.21 (20090318) and the windows version is Turkish language version 2.0.0.21 (20090302). It has been reproduced on more than one computer, windows xp-pro fully updated, Linux ubuntu hardy and a clean windows in a virtualbox session.

Comment 9

[rsx11m]

Comment on attachment 368883 [details]
shows mail forwarding problem on linux and windows

This example indeed has the same structure as handled in bug 337576, matching
the 3rd case in bug 307023 comment #8 with an additional level of nesting. However, it is different from the structure of attachment 321326 [details] which
corresponds to the primary case handled in bug 307023. Also, not using base64.

Marking obsolete so not to confuse test cases to be considered here.