#903 Include attachments in forwarded messages

[sosnovsky]

This PR adds attachments support for forwarded messages

close #903

---

Tests (delete all except exactly one):

• Tests added or updated - updated UI test to check attachment presence

---

To be filled by reviewers

I have reviewed that this PR... (tick whichever items you personally focused on during this review):

• addresses the issue it closes (if any)
• code is readable and understandable
• is accompanied with tests, or tests are not needed
• is free of vulnerabilities
• is documented clearly and usefully, or doesn't need documentation

[sosnovsky]

@tomholub I currently have only 2 assigned tasks left - #953 and #840, can you please check which tasks should I work after these ones?

[tomholub]

Very gladly :-)

[tomholub]

Looks good! Will test. Comments below.

[tomholub]

I got this when forwarding a 9+ mb video. But maybe that's for another issue?

This was after it already spent some time uploading. So if we're uplaoding a large message, we should have higher timeout? Or the timeout should be based on "how long we didn't send any bytes for" vs "how long it took overall"

[tomholub]

I've encountered the following issues

xlsx files malformed when forwarding

1. open a plain message that has a xlsx file in it
2. forward it encrypted
3. open on a laptop with FlowCrypt
4. downloaded file doesn't get recognized as a xlsx file. It does have the right extension, and it does seem to have the right contents. But maybe the mime-type is wrong / not preserved. Compare to forwarding with browser extension, which works. (issue also present on a jpeg file, and likely most others)

changed subject not recognized when forwarding

1. open a message (tested with encrypted but probably applies to both)
2. forward
3. change subject
4. send
5. inspect headers of sent message. It will wrongly have the subject of the original conversation, not the one I edited.

[tomholub]

I suppose the xlsx files malformed when forwarding issue should be coupled with some unit test as it seems an easy thing to break again in the future.

[sosnovsky]

4. downloaded file doesn't get recognized as a xlsx file. It does have the right extension, and it does seem to have the right contents. But maybe the mime-type is wrong / not preserved. Compare to forwarding with browser extension, which works. (issue also present on a jpeg file, and likely most others)

I tried to reproduce this issue, but .xlsx file opens well after forwarding from iOS. Maybe it happens only with some specific files, I forwarded the same message to your email, can you please check if it works or not for you?

[tomholub]

4. downloaded file doesn't get recognized as a xlsx file. It does have the right extension, and it does seem to have the right contents. But maybe the mime-type is wrong / not preserved. Compare to forwarding with browser extension, which works. (issue also present on a jpeg file, and likely most others)

I tried to reproduce this issue, but .xlsx file opens well after forwarding from iOS. Maybe it happens only with some specific files, I forwarded the same message to your email, can you please check if it woraks or not for you?

The issue (missing mime type inside the encrypted enclosure) is present on all files. But the user-facing problem (can't open as a result) only manifests on some host OS, and possibly only for some file types.

[sosnovsky]

I tested sending and forwarding message with 2 attachments (image and xls file) - in both cases app sends right content-types (image/jpeg and application/vnd.openxmlformats-officedocument.spreadsheetml.sheet) to Core.composeEmail function.
Then I downloaded these attachments from browser on macOS and checked mime types - they were the same as sent by the app.
So I think we should create another issue for finding why attachments mime-type is wrong on Linux OS, as it's not only for forwarded messages. May be some difference in decrypting .pgp files.

[tomholub]

Ok. I'll let this merge and we'll investigate it separately.