GNOME Bugzilla – Bug 743676
Missing CID-referenced images
Last modified: 2015-02-13 21:33:17 UTC
Created attachment 295723 [details] Email displaying the problem. Most of the headers have been trimmed, and the base64 data has been removed. The attached email has two images (Content-Disposition: inline) referenced by CID srcs in <img> elements. When viewed in Geary, the HTML mail is displayed, but the image elements are missing entirely. The HTML and the images are each MIME parts within a multipart/related MIME part (which I've never seen before) which is a one part of the whole multipart/alternative message. Perhaps this double nesting is throwing us off?
I think when you were here I mentioned I wasn't happy about how we handle images. This is kind of what I'm talking about. Every time I wade into that code I'm thoroughly confused as to what's going on -- there's a loop that determines what's an attachment and what's not, and there's a callback for converting inline images into data: URLs. Loading remote images is just another complicating factor. Apple/iOS Mail seems to enjoy doing oddball things with MIME...
I've been looking into this one and have found the problem. In Apple iOS Mail (perhaps desktop too), the mail message structure look something like this: --MultipartBoundary-- Content-Type: text/html <html> <head>...</head> <body>text<img src="cid:XYZZY">more text</body> </html> --MultipartBoundary-- Content-Type: image/jpeg Content-Id: <XYZZY> (base-64 data) --MultipartBoundary-- The problem is that our inline image replacer (used within RFC822.Message.get_body) replaces the second multipart section with an IMG tag right where it's located relative to the HTML document, resulting in: <body>text<img src="cid:XYZZY">more text</body> </html><img src="data:base64..."> That in turn is fed to insert_html_markup in the conversation viewer, which drops everything outside of the BODY block (including the replaced IMG tag) as well as dropping the original IMG tag because we replaced it with a data: URI. It's been some time, but it looks like we assumed the multipart section holding the image data would be located within the HTML document itself(??) Or am I missing something here? In either case, what we *really* want is to replace that original IMG tag directly rather than hoping to place things correctly due to the MIME structure. I'll continue looking at this. Robert, if you have any suggestions or thoughts, would be welcome to hear them.
Robert, I've pushed a candidate fix to wip/743676-cid. Could you check it out with your messages and verify this solves the problem? I have some messages at home I would like to verify against as well before committing. The missing link here was that Apple is very active in using multipart/mixed, multipart/alternative, and multipart/related content-types. Previously we passed around a flag indicating if it was alright to use the inline image replacer's HTML, but it was ultimately a guess on our part. By examining the multipart subtype we have a better idea of the part should be inserted into the document in-place or is destined to be referred to by the document (or simply is an attachment). At least, I think. MIME is a hairy beast indeed.
That works for me!
Worked for me too at home. I'll go ahead and merge into master.
Pushed to master, commit 89ca01