799827 - [email] Complete implementation of e-mail share activity triggered by gallery app (allow attaching images)

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::E-Mail, defect, P1)

Description

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

For the feature freeze, we managed to land 2 pieces of the share activity (previously of https://github.com/mozilla-b2g/gaia/issues/2543) relating to the front end:
- Register the e-mail app as a share provider that can be used by the gallery
- UI code to expose attachments in the compose window.

What was lacking are:
- MailAPI public API code to add an attachment
- Providing the contents of the data URI that provides the image as provided by the activity to use that API
- Backend hookup to pass that attachment data into the mailcomposer library we use for mail composition.

Because this is primarily limited book-keeping and use of an existing library that already does a lot of the hard work of sending attachments, this is not particularly difficult.  If we implement draft support, it becomes a little more complicated; the main trade-offs for that are:

- Draft messages on IMAP must be rewritten from scratch each time for stock IMAP servers, and certainly the Yahoo IMAP server.  We can't upload the picture independently of revisions of the text without leaving multiple messages hanging about, and that's complicated for re-opening the drafts.

- Because the image is provided to us as a data URI (as of a few weeks ago when I checked) rather than a location on the device-storage, if we don't save off the picture, we effectively lose access to it.  (If we are using file-share instead of a data URI, that works better.  It's not clear if we could make gallery use that instead for just us, etc.)


I think the simplest way of dealing with the drafts situation there is not to write the image to the draft and only save the text.  Arguably the choice of the image by the user is low entropy and the user can re-select the picture if they desire, so the key thing to preserve on the server is the text the user writes.  If we do get share-file, we can just write an attachment like how Thunderbird handles detaching the file to local storage.

Comment 1

[Dylan Oliver [:doliver]]

Nominated for basecamp -- Chris Lee says must have in v1, especially if we don't have MMS.

Comment 2

[Mark Finkle (:mfinkle) (use needinfo?)]

Can we separate the Draft and Sharing issues, if it becomes a problem getting this implemented?

Comment 3

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

Yes.  We could simply not save drafts if there is an attachment.

Comment 7

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

Back-end patch for this is up for review at:
https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/68
Front-end patch is up at:
https://github.com/mozilla-b2g/gaia/pull/6014

(The patches implement both sharing and downloading attachments because the unit tests really want both available to test round-tripping.)

Comment 8

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

The patches from comment 7 have been marked r=squib and accordingly landed.

This has landed on gaia-email-libs-and-more/master:
https://github.com/mozilla-b2g/gaia-email-libs-and-more/commit/d0782b2b16880799127e6bf46cc40cc4f31ab8c1

This has landed on gaia/master:
https://github.com/mozilla-b2g/gaia/commit/6c04462a5a43ec76606c591f0b4a6552412610bf


This does not yet close out this bug because bug 796729 changes the share activity to use blobs and we want to update our gaia code to do that once the patch gets approval and lands.

Comment 9

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

The patch for bug 796729, https://github.com/mozilla-b2g/gaia/pull/6048 includes the blob fix, so now we are just waiting on approval for that patch to land before we can mark this fixed.

Comment 10

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

The blobs-instead-of-data-uris patch has landed on bug 796729, so this is fixed.

Comment 11

[Mila Davydova]

Verified with Unagi, Build ID 20130103070201
User is able to attach a photo from gallery and send an email.