In the recent "Delivery Report" function included into FFOS. But, this feature does not works correctly. 1. Setting > Cellular & Data > Message settings > "Delivery reports" does not work.(b2g_telephony set this value as "FALSE" by default.) 2. SMS Gaia does not support "Delivery Report"(please refer. Bug 875514). (We changed Gecko(b2g_telephony) code to support "Delivery Report" -> Gecko correctly receive "Delivery Report" of MO-SMS. -> But Gaia cannot receive this event and also does not have any UI's(Icon/Popup...) for receiving "Delivery Report") Why the incompleted function is released? Does vendors required this function strongly? We want to know the history of "Delivery Report". And could we know when the "Delivery Report" fully implemented(SMS Gaia, b2g_telephony, Setting)? Is it possible until 23th Jun? If not, It is hard to add this feature to our(leo) model by schedule problem. This is very urgent. Please let us know ASAP. Mozilla build ID: 20130526070207 Gaia Revision : 4d10e1297b859cacc174c0a54af61a7678d7c32d Gecko Revision : 52341e43539a0e8b9aa77a9128cc3871439b8aa6

Please contact to us. Sunmyoung Lee: sunmyoung.lee1@gmail.com Jaeoh Kim: jaeohkim83@gmail.com

Bug 875514 is still waiting for product team's responding, so we also need more info here. Hi Gene, do we have any event dispatched from mozMobileConnection when report relieved? and is there any attribute to represent the message object is received? A bug link with IDL would be very helpful. If gecko is ready for handling the delivery report, than 23th Jun would be a reasonable deadline.

(In reply to Steve Chung from comment #2) > Hi Gene, do we have any event dispatched from mozMobileConnection when > report relieved? and is there any attribute to represent the message object > is received? A bug link with IDL would be very helpful. If gecko is ready > for handling the delivery report, than 23th Jun would be a reasonable > deadline. I don't get you. The delivery report should have nothing to do with the |mozMobileConnection| thing. The delivery report should be fired through the - nsIDOMMozMobileMessageManager.ondeliverysuccess - nsIDOMMozMobileMessageManager.ondeliveryerror which are going to carry the |nsIDOMMozSmsMessage/nsIDOMMozMmsMessage| DOM object. Again, Gecko only supports this feature for SMS right now. MMS is not in our product scope by far (please see bug 850140; it's koi+).

Just confirmed with Gene, and delivery report handling in gecko is ready. Hi Ayman, we don't define the message status with delivery report back from server. Do you have a brief idea about showing the message is delivered?(Maybe showing the "delivered" string under the outgoing bubble?)

Assuming no info required from product, please re-add and specify what's needed if there is.

referencing comment 4 wireframes detailing proposition for delivery reports. NeedInfo to Kev and Steve to review. Let me know if you need clarification or alterations. wireframes will be included in V9.0 of wireframe pack

Hi Gene, could we get the actual delivered timestamp in gecko? We may need this information. Please ref the wireframe page.3

(In reply to Steve Chung from comment #8) > Hi Gene, could we get the actual delivered timestamp in gecko? We may need > this information. Please ref the wireframe page.3 Both SMS and MMS are doable. Since we don't attempt to implement delivery report for MMS in v1.1, so we don't need to discuss about MMS for now. Regarding the SMS, from the Gecko point of view, we need to take 2~3 days to expose the delivered timestamp in the |nsIDOMMozSmsMessage|.

Hi Ayman, the delivered status seems a little bit redundant because the report icon is displayed only when message is delivered successfully. That means the status is always delivered when user open the report. Do we need to show the status in the report? Victoria, we need your help providing the delivered icon. Could you update the visual asset? Thanks.

In the wireframe page 2, additional notation: We could only raise the notification when message received if not in message app. In the current implementation, changing the message status(like sending to sent successful or failed) will not raise any notification if user is not in message app, and the behavior would be the same when message is delivered.

Hi Gene, ondeliverysuccess event seems not working now. I'm not sure the problem is in dom.sms.requestStatusReport or delivery event dispatch mechanism. Could you please investigate it? Thanks.

(In reply to Gene Lian [:gene] from comment #9) > (In reply to Steve Chung from comment #8) > Both SMS and MMS are doable. Since we don't attempt to implement delivery > report for MMS in v1.1, so we don't need to discuss about MMS for now. Sorry for this naive questoin, but is it different/difficult to do SMS and MMS in the same time?

(In reply to Steve Chung from comment #10) > Hi Ayman, the delivered status seems a little bit redundant because the > report icon is displayed only when message is delivered successfully. That > means the status is always delivered when user open the report. Do we need > to show the status in the report? > > Victoria, we need your help providing the delivered icon. Could you update > the visual asset? Thanks. Hey Steve I agree with you on this and also think that the 'Delivered: timestamp' alone is enough. However I am not completely knowledgeable on the certification requirements around the information that needs to be included the delivery report. Therefore I will defer to Kev. But personally I am happy to drop the string "Status: Received" on the grounds of information redundancy. (In reply to Steve Chung from comment #11) > In the wireframe page 2, additional notation: We could only raise the > notification when message received if not in message app. In the current > implementation, changing the message status(like sending to sent successful > or failed) will not raise any notification if user is not in message app, > and the behavior would be the same when message is delivered. Sorry Steve I am not quite understanding. Are you saying that the following statement (taken from page 2) is achievable or unachievable: "if the user has navigated away from the message app use the phones notification system to inform the user that the message has been successfully delivered. If the user still has the app in focus, do not use the phones notification system." If you are saying that we cannot use the phones notification system to inform the user that a message has been successfully delivered when the user has navigated away from the Messages App then from a UX PoV I do not really see a massive problem in dropping this for v1.1even though all the benchmarks i have referred to inform the user of successful delivery using the phones system notifications if the user has navigated away form the messaging app. However like i say I am not completely knowledgeable on the certification requirements around 'delivery notifications' so i will have to defer to Kev and Beatriz regarding the certification requirements for this. If they agree to drop use of system notification cool, if its a requirement then we need to implement it.

(In reply to Julien Wajsberg [:julienw] from comment #13) > (In reply to Gene Lian [:gene] from comment #9) > > (In reply to Steve Chung from comment #8) > > > Both SMS and MMS are doable. Since we don't attempt to implement delivery > > report for MMS in v1.1, so we don't need to discuss about MMS for now. > > Sorry for this naive questoin, but is it different/difficult to do SMS and > MMS in the same time? From the Gaia point of view, it's exactly the same logic. What you only need to do is to listen for the |nsIDOMMozMobileMessageManager.ondeliverysuccess| event. For SMS, this event will carry an SMS DOM message; for MMS, it will carry an MMS DOM message. However, we've not yet supported delivery report for MMS in Gecko, which means all the |.ondeliverysuccess| event you receive must carry SMS DOM message for now.

(In reply to Steve Chung from comment #12) > Hi Gene, ondeliverysuccess event seems not working now. I'm not sure the > problem is in dom.sms.requestStatusReport or delivery event dispatch > mechanism. Could you please investigate it? Thanks. It's working for me. I'm on the way to find you to clarify.

(In reply to ayman maat :maat from comment #14) > > If you are saying that we cannot use the phones notification system to > inform the user that a message has been successfully delivered when the user > has navigated away from the Messages App then from a UX PoV I do not really > see a massive problem in dropping this for v1.1even though all the > benchmarks i have referred to inform the user of successful delivery using > the phones system notifications if the user has navigated away form the > messaging app. > Yes, that's what I mean. It's not totally inaccessible but it need more extra work from gecko to dispatch the delivered event via system message and popup a notification while away from message app. It would be helpful if we drop this notification feature for v1.1 to reduce the additional efforts in both developing and testing.

(In reply to Gene Lian [:gene] from comment #16) > (In reply to Steve Chung from comment #12) > > Hi Gene, ondeliverysuccess event seems not working now. I'm not sure the > > problem is in dom.sms.requestStatusReport or delivery event dispatch > > mechanism. Could you please investigate it? Thanks. > > It's working for me. I'm on the way to find you to clarify. I discover 2 weird issue, one is my device could not received any delivery event from platform but other devices could work...I might take other device for developing but I will still take some time to figure out the root cause. Another important issue is we're sill able to receive delivery report when the settings option is off. Although we could workaround it in gaia, I think it's not the expected behavior in gecko. Hi Gene, could you verify that dom.sms.requestStatusReport is utilized correctly in mozMobileMessage? Thanks

(In reply to Steve Chung from comment #18) > I discover 2 weird issue, one is my device could not received any delivery > event from platform but other devices could work...I might take other device > for developing but I will still take some time to figure out the root cause. > Another important issue is we're sill able to receive delivery report when > the settings option is off. Although we could workaround it in gaia, I think > it's not the expected behavior in gecko. Hi Gene, could you verify that > dom.sms.requestStatusReport is utilized correctly in mozMobileMessage? Thanks This looks like a Gecko bug. Vicamo is helping with this.

(In reply to Steve Chung from comment #18) > Another important issue is we're sill able to receive delivery report when > the settings option is off. Although we could workaround it in gaia, I think > it's not the expected behavior in gecko. Hi Gene, could you verify that > dom.sms.requestStatusReport is utilized correctly in mozMobileMessage? Thanks http://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/ril_worker.js#3796 http://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/ril_worker.js#3973 That's not supposed to happen if "dom.sms.requestStatusReport" is correctly set. ril_worker skips waiting for SMS-STATUS-REPORT if per transaction "requestStatusReport" attribute is not set to true. But, yes, we need to find out the root cause.

(In reply to Steve Chung from comment #17) > (In reply to ayman maat :maat from comment #14) > > > > If you are saying that we cannot use the phones notification system to > > inform the user that a message has been successfully delivered when the user > > has navigated away from the Messages App then from a UX PoV I do not really > > see a massive problem in dropping this for v1.1even though all the > > benchmarks i have referred to inform the user of successful delivery using > > the phones system notifications if the user has navigated away form the > > messaging app. > > > > Yes, that's what I mean. It's not totally inaccessible but it need more > extra work from gecko to dispatch the delivered event via system message and > popup a notification while away from message app. It would be helpful if we > drop this notification feature for v1.1 to reduce the additional efforts in > both developing and testing. ok, well like I say I am waiting on a decision from product on whether we can drop this or not.

Hi, The delivery status indicator visual design is ready. I am attaching the layout screen illustrating the position of the icon, the icons assets in both sizes 1x and 2x, and the overlay specs. This last one should respect the Building Blocks layout, but the information below the title is different from the used until now, so please follow this spec.

Hi, The delivery status indicator visual design is ready. I am attaching the layout screen illustrating the position of the icon, the icons assets in both sizes 1x and 2x, and the overlay specs. This last one should respect the Building Blocks layout, but the information below the title is different from the used until now, so please follow this spec.

I have reviewed some certification requirements but they are very open, they just talked about the necessity of having the delivery report functionality working fine from a customer perspective. However there is no more specification about how to handle it in the system. Thanks for asking and sorry for my delay.

Hi Beatriz, I create a gecko issue(bug 887159) for delivery report. It need some extra work in gecko to expose the timestamps. Could you please confirm that we can move this information page to v1.2 and just shows the delivered icon in message for v1.1? Thanks.

Hi Steve, I can confirm that we can go without the timestamp information(although it is not the desired behaviour but we can understand the time constraints) and we hope we can have it ready in 1.2. Adding ni for Aymman, so he can update wireframes based on the information available.

Taking a look! :)

Comment on attachment 767789 [details] Patch for complete the delivery report feature Thanks Steve! SMS App is ready for having double check hehehehe ;)

https://github.com/mozilla-b2g/gaia/commit/40a45fcd773a05e4e6fec517b43f0fdc7f664525 https://github.com/steveck-chung/gaia/commit/126eebc0185f9e20f2423143854da3cda89620b2 R+. Landed!

Uplifted 40a45fcd773a05e4e6fec517b43f0fdc7f664525 to: v1-train: f3f12c78aad484d62ce1287cdb4c158cb8c7305e

v1.1.0hd: f3f12c78aad484d62ce1287cdb4c158cb8c7305e

Tested on Unagi device. Gecko-2b310a1.Gaia-2e711c1 Build Id: 20130714175847 Platform Ver. 18.1 Comm RIL: AU158 New MOZTRAP Test Cases created: https://moztrap.mozilla.org/manage/case/9015/ https://moztrap.mozilla.org/manage/case/9016/ https://moztrap.mozilla.org/manage/case/9017/ https://moztrap.mozilla.org/manage/case/9018/ All tested and work ok