Closed Bug 799827 Opened 8 years ago Closed 8 years ago

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


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




blocking-basecamp +


(Reporter: asuth, Assigned: asuth)



(Whiteboard: [LOE:S])

For the feature freeze, we managed to land 2 pieces of the share activity (previously of 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.
Nominated for basecamp -- Chris Lee says must have in v1, especially if we don't have MMS.
blocking-basecamp: --- → ?
Can we separate the Draft and Sharing issues, if it becomes a problem getting this implemented?
blocking-basecamp: ? → +
Priority: -- → P1
Yes.  We could simply not save drafts if there is an attachment.
Summary: [email] Complete implementation of e-mail share activity triggered by gallery app → [email] Complete implementation of e-mail share activity triggered by gallery app (allow attaching images)
Assignee: nobody → bugmail
Whiteboard: [LOE:S]
Duplicate of this bug: 801197
Duplicate of this bug: 804843
Depends on: 805532
Back-end patch for this is up for review at:
Front-end patch is up at:

(The patches implement both sharing and downloading attachments because the unit tests really want both available to test round-tripping.)
Priority: P1 → --
Priority: -- → P1
The patches from comment 7 have been marked r=squib and accordingly landed.

This has landed on gaia-email-libs-and-more/master:

This has landed on gaia/master:

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.
Depends on: 796729
The patch for bug 796729, includes the blob fix, so now we are just waiting on approval for that patch to land before we can mark this fixed.
The blobs-instead-of-data-uris patch has landed on bug 796729, so this is fixed.
Closed: 8 years ago
Resolution: --- → FIXED
Verified with Unagi, Build ID 20130103070201
User is able to attach a photo from gallery and send an email.
You need to log in before you can comment on or make changes to this bug.