Closed Bug 478175 Opened 16 years ago Closed 16 years ago

multipart/related creates duplicate child at unexpected position, resulting in confusion for multipart/alternative children

Categories

(MailNews Core :: MIME, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.0b2

People

(Reporter: asuth, Assigned: asuth)

References

Details

Attachments

(1 file)

The code that processes multipart/related defers processing of the 'head' object until it has processed all of its other children. It leaves a dummy instance (its buffer is never processed) of the 'head' object child, and appends a duplicate instance that is fully processed. If the duplicate instance has children (for example, multipart/alternative), this results in confusing paths being generated and reported to the JS MIME Emitter (added in bug 447842) Example: Actual message MIME hierarchy: 1 multipart/mixed 1.1 multipart/related 1.1.1 multipart/alternative 1.1.1.1 text/plain 1.1.1.2 text/html (terminate) 1.1.2 image/jpeg (terminate) (terminate) Apparent MIME hierarchy: 1 multipart/mixed 1.1 multipart/related 1.1.1 multipart/alternative 1.1.2 image/jpeg 1.1.3 multipart/alternative (DUPLICATE) 1.1.3.1 text/plain 1.1.3.2 text/html Because of the way multipart/related processes its buffers, the JS emitter only hears about 1.1.1 and 1.1.2, never 1.1.3, so it gets surprised when 1.1.3.1 shows up. The provided patch changes things so that instead of appending and duplicating the fully parsed node, we instead replace the dummy node. For downstream consumers, things should generally look the same, but end up 'more correct'. (The paths change, but are consistent in generation and retrieval, and the event stream stays the same because the order of processing stays the same. Only the JS Emitter should notice a difference.) Because freeing an object can do weird things, we don't actually free the dummy node until the related node goes away. (Most specifically, options->state gets cleaned up, but we don't want to hamstring those wacky MIME classes from doing whatever they want to do.)
Attachment #361951 - Flags: superreview?(bienvenu)
Attachment #361951 - Flags: review?(bienvenu)
Assignee: nobody → bugmail
Status: NEW → ASSIGNED
Target Milestone: --- → Thunderbird 3.0b2
(This blocks bug 465113 which is itself a blocker.)
Flags: blocking-thunderbird3?
Attachment #361951 - Flags: superreview?(bienvenu)
Attachment #361951 - Flags: superreview+
Attachment #361951 - Flags: review?(bienvenu)
Attachment #361951 - Flags: review+
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Flags: blocking-thunderbird3?
This also fixes a problem with mails which use multipart/related wrongly, apparently sent my some Microsoft client. multipart/related; type="multipart/mixed" (Nonsense) multipart/mixed (With attachments) multipart/related; type="multipart/alternative" (Nonsense) multipart/alternative (Choose Plaintext or HTML) text/plain (Plaintext version of the body) text/html (HTML version of the body) image/png (Picture embedded in HTML text) application/msword; name="Programa.doc" (Attachment) image/png (again the same picture embedded second time in HTML text) image/png (Picture embedded in HTML text) Without the patch, Thunderbird shows the attachment, but when you try to save it, the file ends up being 0 bytes. With this patch, you can save it. (This should be, and Thunderbird would do: multipart/mixed (With attachments) multipart/alternative (Body - Choose Plaintext or HTML) text/plain (Plaintext version of the body) multipart/related (Embed objects in HTML) text/html (HTML version of the body) image/png (Picture embedded in HTML text) image/png (Picture embedded in HTML text, this one used 2 times) application/msword; name="Programa.doc" (Attachment) )
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: