Summary: [B2G][SMS][MMS] Support new system message of "sms-delivery-error" to notify the error from delivery report. → [B2G][SMS][MMS] Support new system message of "sms-failed" & "sms-delivery-error" to notify both sent error and the error from delivery report.

(In reply to Julien Wajsberg [:julienw] from comment #3)
> I'm actually more interested by sms-failed. Do we have the same issue with a
> frozen RIL interface for this event ?
Unfortunately, yes, we don't expect directly access to the system messenger API by vendor's RIL after interface is frozen in 2.2 to prevent any API changes in system messenger that breaks vendor's binary release in the future.
That's why we create nsISmsMessenger in [1] as a proxy to restrict the sms-related system messages requested by vendor.
In this bug, what we have to do is to
1. define new nsISmsMessenger.NOTIFICATION_TYPE_XXX for "sms-failed" & "sms-delivery-error" and implement the broadcast of the corresponding system messages.
2. call nsISmsMessenger.notifySms with new types defined above in SmsService.js.
(Note: MmsService is not replaced by vendor, so we can call the System Messenger APIs directly.)
However, for vendor's binary release, this newly-added feature will only be completed after step 2) is done in vendor's implementation.
[1] https://hg.mozilla.org/mozilla-central/file/eea6188b9b05/dom/mobilemessage/interfaces/nsISmsMessenger.idl#l16

(In reply to Bevis Tseng[:bevistseng][:btseng] from comment #4)
> (In reply to Julien Wajsberg [:julienw] from comment #3)
> > I'm actually more interested by sms-failed. Do we have the same issue with a
> > frozen RIL interface for this event ?
>
> Unfortunately, yes, we don't expect directly access to the system messenger
> API by vendor's RIL after interface is frozen in 2.2 to prevent any API
> changes in system messenger that breaks vendor's binary release in the
> future.
> That's why we create nsISmsMessenger in [1] as a proxy to restrict the
> sms-related system messages requested by vendor.
>
> In this bug, what we have to do is to
> 1. define new nsISmsMessenger.NOTIFICATION_TYPE_XXX for "sms-failed" &
> "sms-delivery-error" and implement the broadcast of the corresponding system
> messages.
> 2. call nsISmsMessenger.notifySms with new types defined above in
> SmsService.js.
> (Note: MmsService is not replaced by vendor, so we can call the System
> Messenger APIs directly.)
>
> However, for vendor's binary release, this newly-added feature will only be
> completed after step 2) is done in vendor's implementation.
>
Thanks Bevis for the detailed explanation! I just want to add a remark that the situation of vendor RIL support is the same as before when we didn't freeze ril interfaces. That is, there isn't a new feature in vendor's release until it's done in vendor's implementation.

(In reply to Julien Wajsberg [:julienw] from comment #3)
> I'm actually more interested by sms-failed. Do we have the same issue with a
> frozen RIL interface for this event ?
Hi Julien,
IMO, it's more important to have "sms-delivery-error" system message because it's a standalone event that is not related to any pending DOMRequests and it provides a proactive way to notify user the status of sent messages.
I am curious to know why "sms-failed" is more interesting to you when this will be notified by the callback of the DOMRequest.
My understanding is that you need a notification when message app is in the background after a message is sent to allow user to launch the message app again.
Is this the only reason or do your expect that there is another app requires this type of message for different purpose?
Thanks!

No, it's really for the SMS application only.
The main issue issue is that sending a message can take time (especially for MMS!) and the application can be killed before we get an error, and in that case we'd never have the request's onerror handler.
I say it's the most important because that's basic functionality. We can still do the part that does not need the system message of course.

Created attachment 8588968[details][diff][review]
Part 1 v1: Define new system messages of "sms-failed" and "sms-delivery-error".
This is to define new system messages of "sms-failed" & "sms-delivery-error" to be applied by SmsService/MmsService.
Hi Edgar,
May I have your review for this change?
Thanks!

Attachment #8588968 -
Attachment description: Part 1 v1: Define new system messages of "sms-failed" and "sms-delivery-error". r=echen. → Part 1 v1: Define new system messages of "sms-failed" and "sms-delivery-error".

Created attachment 8588969[details][diff][review]
Part 2 v1: Broadcast System Messages from SmsService/MmsService accordingly.
This is to broadcast these new defined messages from SmsService/MmsService accordingly.