UCID: Messages-033 User Story: As a user, I can attach the following content types from the compose dialog for the purpose of sharing said content easily via MMS: images, audio, video (as attachements, using currently supported MIME types) or text, URIs (within message body)

CJ, can you take this for now and reassign as needed? thanks

Attaching images, video, music and from camera UX: https://www.dropbox.com/s/zc3hhd1mxi16p4w/MMS.pdf links, email addresses and phone numbers should be handling should be as per spec: https://www.dropbox.com/s/0f3gpv2rkqupeq6/Messaging-Email%2BBrowserLinks.pdf

Multimedia format compliance will be checked against OMA-TS-MMS-CONF-V1_3-20110913-A section 7, and Appendix C.1.2

(In reply to Casey Yee [:cyee] from comment #2) > Attaching images, video, music and from camera UX: > https://www.dropbox.com/s/zc3hhd1mxi16p4w/MMS.pdf > Should we need to add "camera" to be triggered directly from the attachment button? We can execute camera app from Gallery. So, if we allow users to go to Gallery first, then if users want to take a shot, users can execute camera from the Gallery app. After taking a shot, users can go back to Gallery, choose the photo and attach. Will it be better and can narrow down the testing efforts?

Per partner and release-driver discussions, marking blocking- until all MMS functionality in bug 849867 is complete, allowing it all to be uplifted at once to avoid SMS bustage.

(In reply to Peter Dolanjski [:pdol] from comment #0) > UCID: Messages-033 > > User Story: > As a user, I can attach the following content types from the compose dialog > for the purpose of sharing said content easily via MMS: images, audio, video > (as attachements, using currently supported MIME types) or text, URIs > (within message body) URIs (within message body). what exactly should this do?

Hi Joe, clickable hyperlink is already implemented in https://bugzilla.mozilla.org/show_bug.cgi?id=838005. It will apply web activity and browser will open the link.

what's the status on this one? it seems like this is already supported? thanks

This bug is mostly like a meta-bug, three categories of attachement is mentioned in the user story: 1. images, audio, video: details in bug 840082 2. text: basic functionality of MMS message composer 3. URIs (within message body): details in bug 838005 IMO this bug could be closed since all three items above were completed.

per comment 9

(In reply to Joe Cheng [:jcheng] from comment #10) > per comment 9 We can not resolve this US yet. Shih-Chiang Chien says that the 1. images, audio, video: details in bug 840082, and although it's resolved, it's only the Gecko side, not the User Interface. Do you know there is another bug tracking that work? I think there is not (Correct me if I am wrong, please) so we should keep this US for tracking all this work, in fact this US ahould not be resolved, at least, until bug 849766 and 849768 that handles the pick activities for Audio and Video are resolved

Nominating as leo+, as this is one of the MMS P1 US. Adding [NO-UPLIFT] whiteboard, as it can not be uplifted until the complete MMS functionality is ready.

Updating this bug to track only the image attachment portion of attaching from the composition screen in MMS. As audio and video aren't necessary for v1.1, they will be their own, lower priority bugs.

This patch is far from complete; it is meant to track my recent work around this bug. Greg: if you want to pick it up from here, careful with the CSS. The rules for buttons is mostly contained in a stylesheet shared across Gaia. This makes it tricky to override consistently.

Comment on attachment 744954 [details] [diff] [review] Work in progress Dan has created Bug 869255 to track the implementation of the "Attach" button. This patch concerns that aspect of the user story, so I'm marking it as obsolete and continuing work on the more specific bug.

This bug is specifically the work of handling the mozActivity-returned blob and attaching it to the message. This *might* include some changes to Attachment.js Attachment.prototype.render method, but is namely the work of receiving pick's and using them.

This work is based on the patch submitted for Bug 869255 and should not be landed prior to it. Note also that while this patch implements the described UI, attachment content is currently "scrubbed" upon message transmission. I have created Bug 871835 to further explain that issue and to track the resolution.

Comment on attachment 749063 [details] [diff] [review] Implement support for image attachment Review of attachment 749063 [details] [diff] [review]: ----------------------------------------------------------------- ::: apps/sms/js/compose.js @@ +268,2 @@ > */ > + requestAttachment: function(options = {}) { Since the underlying form of this async op is a activity, do you think we should return an object that you can add `onsuccess` / `onerror` to? Keep the same API as activity? ::: apps/sms/test/unit/compose_test.js @@ +5,5 @@ > > mocha.globals(['0']); > > requireApp('sms/js/compose.js'); > +requireApp('sms/js/attachment.js'); You already have mock_attachment, you should be able to use this instead yeah? @@ +227,5 @@ > + }); > + test('Invokes the provided "failure" handler when the MozActivity fails', > + function(done) { > + Compose.requestAttachment({ > + failure: done I don't like that there are zero assertions here, can you add a function just to assert.ok(true) before calling done?

This version of the patch addresses Corey's feedback in comment 18. Specifically, it: - Modifies the `requestAttachment` API to mimick the underlying DOMRequest returned by MozActivity - Uses the `mockAttachment` file in the test suite - Implements an empty assertion to promote unit test readability

Comment on attachment 749523 [details] [diff] [review] Implement support for image attachment Review of attachment 749523 [details] [diff] [review]: ----------------------------------------------------------------- ::: apps/sms/js/compose.js @@ +285,5 @@ > + var type = result.type.split('/')[0]; > + var attachment = new Attachment(type, objectURL, blob.size); > + > + if (typeof requestProxy.success === 'function') { > + requestProxy.success(attachment); if we are using onerror we should also use onsuccess ?

Correct a discrepancy between the object returned by `requestAttachment` and the DOMRequest API that it mimics.

Comment on attachment 749529 [details] [diff] [review] Implement support for image attachment Review of attachment 749529 [details] [diff] [review]: ----------------------------------------------------------------- Looks good to me! Lets land the pair.

Landed at commit: a09e770ecd5d80c9e04480b861ddf1b0d28669f6

v1-train:82841ef