UCID: Messages-017 User Story: As a user, I can compose an MMS message to a contact (or recipient address) directly from any media application (e.g. Gallery, Music Player, and Video Player) for the purpose of easily sending a contact an MMS message with media from the respective application attached pre-populated with recipient information.

How about DRM files ? Maybe we can show an special icon and pop-up warning message when user want to select it ?

This requirement is covered on pages 3, 4, 5 and 6 in the MMS spec: https://www.dropbox.com/s/zc3hhd1mxi16p4w/MMS.pdf Any comment or feedback welcome!

Hi there, This feature would be as 'share' button in Gallery right? Could you confirm this behaviour? Because this bug could be 'Implement new activity for creating a MMS with multimedia content', but we would need extra bugs for applying this new feature to other apps.

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.

Since user can select multiple miedia items and take action in group, will we have such scenario other than attaching/sharing them one by one? Thanks for confirmation.

leo+ as this is a part of MMS and part of v1.1 to be included in leo+ queries. No_UPLIFT for now before the whole MMS is completed

Paul, I'm not quite sure if I am understanding your question. Are you asking if the user can pick more than 1 file at a time? I would expect that similar to Bluetooth sharing, you should only be able to select a single file at a time. Redirecting request to Ayman to confirm since he is responsible for the UX.

Oops. I accidentally changed the in-moztrap flag and am not sure how to fix this. Sorry!

Hi Casey, sorry for late reply, Actually we may select more than one photo and share them at once. The steps are, 1. open gallery app 2. tap on right button at the bottom (with a square icon) 3. select as many photos 4. tap "share" button at the bottom (a "C" shape icon) Sorry it's quite hard to describe clearly, Just try on v1train phone and it works.

Hi Casey, Just confirm with Bluetooth stakeholder, Currently bluetooth can't send more than one file because it is under-construction.

moztrap #6764, #6765, #6766, #6864

redirecting to Rob as he is covering this area

MMS is being handled by Francis (fdjabri@mozilla.com) and Casey whereas I'm handling media apps. Since there seems to be some overlap with this bug, feel free to flag any of us (or Stephany Wilkes) if there are any gaps in the UX docs or questions. Thanks!

(In reply to Peter Dolanjski [:pdol] from comment #0) > UCID: Messages-017 > > User Story: > As a user, I can compose an MMS message to a contact (or recipient address) > directly from any media application (e.g. Gallery, Music Player, and Video > Player) for the purpose of easily sending a contact an MMS message with > media from the respective application attached pre-populated with recipient > information. I'm working on implementing this functionality now, but I am not sure what is intended by "from the from the respective application attached pre-populated with recipient information." As I understand it, the user is entering the Messaging application directly from some other app (such as the Gallery) and has had no opportunity to specify a recipient at this point in the interaction. I've searched the latest specification on the wiki[1] (the link in comment 2 has gone stale), and I can't find any more information on this. Any clarification would be very helpful! [1] https://wiki.mozilla.org/Gaia/SMS

I'm also confused by the user story. We'll definitely need more clarity from Product on this one. I see this working in two different ways: 1. select contact -> new message (with contact pre-populated) -> attach media file -> send message Or 2. select media -> new message (message pre-populated with attachment) -> add recipient -> send message. The user story seems to suggest being able to do both simultaneously?

In advance of clarification from product on my question in comment 14, I've implemented what I interpret to be the desired behavior. This patch includes refactoring necessary for testability (which bug 867885 depends on). I am in the process of adding a few unit tests, but I'm interested in getting some feedback in the mean time.

Comment on attachment 750623 [details] [diff] [review] Share activity support (wip) Review of attachment 750623 [details] [diff] [review]: ----------------------------------------------------------------- I haven't tested, but code looks solid as a first patch. Just a couple of small `this` based questions, and somewhere there was a strange argument. I know you're still working on tests so I'll wait for that patch to come through to give it r+ ::: apps/sms/js/activity_handler.js @@ +5,5 @@ > > +var ActivityHandler = { > + init: function() { > + window.navigator.mozSetMessageHandler('activity', > + ActivityHandler.global); Any reason not to this.global.bind(this) to be like the rest of the event handle binds we've been writing lately. @@ +10,5 @@ > + > + // We want to register the handler only when we're on the launch path > + if (!window.location.hash.length) { > + window.navigator.mozSetMessageHandler('sms-received', > + ActivityHandler.onSmsReceived); same @@ +13,5 @@ > + window.navigator.mozSetMessageHandler('sms-received', > + ActivityHandler.onSmsReceived); > + > + window.navigator.mozSetMessageHandler('notification', > + ActivityHandler.onNotification); same @@ +20,5 @@ > + // The Messaging application's global Activity handler. Delegates to specific > + // handler based on the Activity name. > + global: function activityHandler(activity) { > + var name = activity.source.name; > + var handler = ActivityHandler.handlers[name]; this? @@ +64,5 @@ > + if (window.location.hash !== '#new') { > + window.addEventListener('hashchange', insertAttachments); > + window.location.hash = '#new'; > + } else { > + insertAttachments(false); why the argument?

This patch addresses Corey's previous review. Although the tests are still not complete, I am uploading this patch so it may be landed in my absence (if necessary).

Comment on attachment 750636 [details] [diff] [review] Share activity support (wip) Review of attachment 750636 [details] [diff] [review]: ----------------------------------------------------------------- Let's get this landed. I'd still prefer if you wrote some simple tests to go with it early tomorrow, I'm not in so much of a rush to turn down unit tests!

This version implements unit tests for the new functionality and also corrects code indentation. I recommend `git diff --ignore-space-change` to review the significant changes. I've also corrected an additional rendering bug that occurred when transitioning from "Edit" views (in Thread UI or Thread List UI) directly into "New Message".

Landed at commit ef9cff8743903034ffa8b33e8ed3ec8c3bd74b1f If anyone I've flagged for more information feels that we have mis-interpreted the user story, please open a new bug describing how the functionality should be modified.

v1-train: eab462b

Kev, can you verify the implementation?