Currently the whole email, including attachment content, is loaded on selecting the email. This makes that very slow (so no email headers or body visible) when it has large attachment(s).
(Actually, a lot slower than I would expect it to be, given there's no network involved, but that's not the point.)
Attachment content should load asynchronously (if deferred to opening the attachment, that would be slow) and not delay the rendering of the email body.
This is a lot more complex than it sounds, since in order to find either the body or possible attachments, we have to parse the email; so this requires either that the 'read body' API abort early, or some asynchronous parsing of the whole thing into an object read by synchronous methods that just block on their respective field being filled.
Note also that off the top of my head, I don't think the body (inline parts) are required to strictly precede attachments. So worst case, this offers no improvement. (We could scan the whole thing looking for part start locations quickly I suppose? Not sure that's worth it. Perhaps examine real-world examples to see how often that would help significantly.)
Currently the whole email, including attachment content, is loaded on selecting the email. This makes that very slow (so no email headers or body visible) when it has large attachment(s).
(Actually, a lot slower than I would expect it to be, given there's no network involved, but that's not the point.)
Attachment content should load asynchronously (if deferred to opening the attachment, that would be slow) and not delay the rendering of the email body.
This is a lot more complex than it sounds, since in order to find either the body or possible attachments, we have to parse the email; so this requires either that the 'read body' API abort early, or some asynchronous parsing of the whole thing into an object read by synchronous methods that just block on their respective field being filled.
Note also that off the top of my head, I don't think the body (inline parts) are required to strictly precede attachments. So worst case, this offers no improvement. (We could scan the whole thing looking for part start locations quickly I suppose? Not sure that's worth it. Perhaps examine real-world examples to see how often that would help significantly.)