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

Status: RESOLVED FIXED

(MailNews Core :: MIME, defect)

Description

[Andrew Sutherland [:asuth] (he/him)]

Attachment: v1 replace dummy node with fully parsed version

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.)

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

(This blocks bug 465113 which is itself a blocker.)

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

pushed http://hg.mozilla.org/comm-central/rev/f0bdc29e9c1c

Comment 3

[Ben Bucksch (:BenB)]

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)
)