805799 - [WebAPI] WebSMS: Receiver/sender fields are 'null' when the onreceived/onsent events are fired

Status: RESOLVED DUPLICATE of bug 823010

(Core :: DOM: Device Interfaces, defect)

Description

[Robert Wood [:rwood]]

Attachment: Marionette b2g emulator test

When receiving an SMS and the 'onreceived' smsmanager event is received, the corresponding smsmessage.receiver value is null.

However if smsmanager.getMessage is then used to get the same sms message that was just received, the sms returned now has the smsmessage.receiver value set to the emulator's phone number as expected.

I had expected the smsmessage.receiver value to be populated right away and be available when the onreceived sms event is received (instead of being null).

Also the similar situation, when an SMS is sent using smsmanager.send and the sms.onsent event is received, the corresponding smsmessage.sender is null.  However after getting the sent message via smsmanager.getMessage, the returned smsmessage.sender is now the emulator's phone number as expected. Also expected that value to be set right from the beginning when the sms.onsent event was received and not be null.

To reproduce, run the attached marionette b2g test on the emulator (test_sender_receiver.js).

Comment 1

[Vicamo Yang [:vicamo][:vyang]]

I suggest we just fill both fields under all cases. This brings several benefits like 1) ease of search 2) helps identifying originating SIM card for multi-sim setup. Any comments?

Comment 2

[Mounir Lamouri (:mounir)]

Clearly, the current Firefox OS behaviour is buggy and we should not have such an inconstancy. If we can popuplate received/sender we should always have them populated. If we can't, we should do like the Android implementation where they are always null.

Comment 3

[Vicamo Yang [:vicamo][:vyang]]

(In reply to Mounir Lamouri (:mounir) from comment #2)
> Clearly, the current Firefox OS behaviour is buggy and we should not have
> such an inconstancy. If we can popuplate received/sender we should always
> have them populated. If we can't, we should do like the Android
> implementation where they are always null.

I won't say buggy, part of the reasons come from the work flow. We can set receiver address, which is the IMSI of current SIM, in all received messages for sure. But for out going messages, in current implementation, we can also always set originating address, the same with previous one. But when it comes to bug 774621, saving outgoing messages before sending, it's possible that we don't have IMSI (SIM card absent) at the time the user want to send a SMS out. And this is a work-flow problem, not buggy.

Yes, we can't make the fields always come with non-null values for above reason. Then we have only one option left: make them null all the time. Any other comments?

Comment 4

[Mounir Lamouri (:mounir)]

I'm not sure I follow. If you have no SIM card, you can set the number to null, but if you have a SIM card, you put the number. I don't understand what makes this impossible to do.

Comment 5

[Philipp von Weitershausen [:philikon]]

Bug 823010 actually fixed this.