Closed Bug 798719 Opened 8 years ago Closed 7 years ago

[Email] Unable to view or open an attachment

Categories

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

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-basecamp:+)

VERIFIED FIXED
blocking-basecamp +

People

(Reporter: tchung, Assigned: asuth)

Details

Unable to view or open an attachment.   only the filename appears and thats it.

Environment:
- 10/5 daily otoro build
- gaia: ca1f327d5acc198bb4be62fa51db2c039032c9ce
- gecko: ddc8eeb3f9b9ee04d9f74b4f60522eb4530a4a6f

Repro:
1) setup email and add an account (gmail)
2) From another account, send a test email to that account with an attachment.  (i included a .png file)
3) View the email, and verify only the name of the attachment appears.  there's no way to launch or save it.  (in this case, it was a png file, so can't see anything)

Expected:
- view or save the attachment if its a supported format.   

Actual:
- no UI to save or view the attachment from the email.
Assignee: nobody → schung
unable to attach one either.
Summary: [Email] Unable to view or open an attachment → [Email] Unable to view or open an attachment or attach attachment
Attaching an attachment is a completely different code-path and UX flow, so let's not grow the scope of this bug to include that.  I had filed bug 799827 for that and have now updated the bug to include the string "attach" to hopefully make searching for it easier.
Summary: [Email] Unable to view or open an attachment or attach attachment → [Email] Unable to view or open an attachment
blocking-basecamp: ? → +
Priority: -- → P2
Hi Andrew,
Do we have the api to download the attachment and callback with progress? I can only discover downloadEmbeddedImages for all inline images. In this case, maybe we can just handle the multimedia and use storage api : Storage.addNamed(blob, name) to download media into mediaStorage. If attachment download api is ready or ongoing, please notify me and I will start to implement download/view UI flow, thanks.
MailAPI._downloadAttachments is the unexposed API endpoint that already exists for downloadEmbeddedImages but will also be used for attachments.  I think my plan is to expose a download() method on MailAttachment that invokes that method for us. The callback does not currently provide progress.  I think we will need to save progress for a future enhancement because it could end up being a fairly large amount of new plumbing.

I am planning to finish that API out once I get move/deletion's implementation landed.

I don't think we've quite nailed down whether we are going to use DeviceStorage or IndexedDB for storing attachments proper.
Plan is DeviceStorage, trigger "open" activity, we do not cleanup the image on purging from cache.  From telecon.
Note for v1 we are only supporting download/view of image attachments. Other files should display a message indicating unrecognized/unsupported file type.
Whiteboard: [blocked by Gecko]
Assignee: schung → bugmail
Status: NEW → ASSIGNED
Whiteboard: [blocked by Gecko]
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.)
Priority: P2 → --
Priority: -- → P1
The patches from comment 8 have been marked r=squib and accordingly been 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 should close out this bug, but let it be known that djf is planning to change the 'open' activity to use blobs instead of filenames, so the gaia code is expected to be slightly modified in the near future.  That will happen on a new bug, however.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
On the 12.17.21 unagi build users may download and view photo attachments, but not file attachments.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to Rebecca Billings from comment #10)
> On the 12.17.21 unagi build users may download and view photo attachments,
> but not file attachments.

See:

(In reply to Dylan Oliver [:doliver] from comment #7)
> Note for v1 we are only supporting download/view of image attachments. Other
> files should display a message indicating unrecognized/unsupported file type.

There may be a bug to update use cases or test cases or something like that, but given how old this bug is, that needs to be a different bug.
Status: REOPENED → RESOLVED
Closed: 8 years ago7 years ago
Resolution: --- → FIXED
Unagi, build ID 20121217070202

Unable to open an attachment. Attachment icon is shown at the top of the email, but user is not able to open it, tapping it is not loading its content.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
A new bug should be filed in situations like this where the bug has been fixed for more than a few days, and especially in cases where regressions likely have nothing to do with the original implementation.

I'm not sure if this is a regression or a feature request.  Is the attachment in question an image?  If so, it would appear to be related to bug 824190.
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
Verified Fixed for .png file attachments as expressed in the original Bug Description by tchung. This on Unagi Build 20121231070201.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.