1067269 - Outgoing messages not being displayed in conversation.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::SMS, defect)

Description

[Shane Tomlinson [:stomlinson]]

For one contact only, outgoing SMS messages are not being saved to the conversation and I am not sure if the messages are being sent. If I send an SMS to a different contact, everything works as expected. The contact is my wife, and I have successfully sent many messages to her in the past.

ADB logcat shows:

I/LOWI-SERVER(  442): [LOWIController] OSAgent Subscription timer, check and issue subscription request
E/QCALOG  (  427): [MessageQ] ProcessNewMessage: [LOWI-SERVER] unknown deliver target [OS-Agent]
E/QCALOG  (  427): [MessageQ] ProcessNewMessage: [XTWWAN-PE] unknown deliver target [OS-Agent]
E/QCALOG  (  427): [MessageQ] ProcessNewMessage: [XT-CS] unknown deliver target [OS-Agent]
E/QCALOG  (  427): [MessageQ] ProcessNewMessage: [XTWiFi-PE] unknown deliver target [OS-Agent]
E/QCALOG  (  427): [MessageQ] ProcessNewMessage: [XTWWAN-PE] unknown deliver target [OS-Agent]
E/QCALOG  (  427): [MessageQ] ProcessNewMessage: [XT-CS] unknown deliver target [OS-Agent]
E/QCALOG  (  427): [MessageQ] ProcessNewMessage: [XTWiFi-PE] unknown deliver target [OS-Agent]
E/QCALOG  (  427): [MessageQ] ProcessNewMessage: [XTWWAN-PE] unknown deliver target [OS-Agent]
E/QCALOG  (  427): [MessageQ] ProcessNewMessage: [XT-CS] unknown deliver target [OS-Agent]
E/QCALOG  (  427): [MessageQ] ProcessNewMessage: [XTWiFi-PE] unknown deliver target [OS-Agent]
E/QCALOG  (  427): [MessageQ] ProcessNewMessage: [XTWWAN-PE] unknown deliver target [OS-Agent]
E/QCALOG  (  427): [MessageQ] ProcessNewMessage: [XT-CS] unknown deliver target [OS-Agent]
E/QCALOG  (  427): [MessageQ] ProcessNewMessage: [XTWiFi-PE] unknown deliver target [OS-Agent]


Device: Flame
Build ID: 20140910000203

Comment 1

[Shane Tomlinson [:stomlinson]]

This may be related to the phone's time being reset after a dead battery and reboot.

Comment 2

[Shane Tomlinson [:stomlinson]]

More information, the SMS *is* in the conversation log, just in the wrong location. The outgoing messages appear very far back in the conversation.

Comment 3

[Julien Wajsberg [:julienw] (PTO -> may 13)]

Yeah we know such issues happen when the phone's time is reset.

Can you confirm that it works as expected once your time is correctly set?

I don't think we'll ever be able to completely fix this but we can at least try to display an alert (for example when the latest message in the thread is "in the future"). We won't be able to do this if the database is empty of course, but this can be good enough.

What do you think Jenny?

Comment 4

[Jenny Lee]

Hey Julien,

I don't fully understand the issue described here. The outgoing message is saved but not correctly placed in the conversation when somehow time is reset (or phone reboot) during the sending process? 

I thought we always rearrange all the message if there's a time zone change? So theoretically speaking, this shouldn't happen?

Comment 5

[Julien Wajsberg [:julienw] (PTO -> may 13)]

When a message is received or sent, the Gecko API is adding a "timestamp" property to this message. This "timestamp" is retrieved using the local time in the phone, and then never changes again for this particular message. Then we use this timestamp to order the messages and the message threads in the UI. Note that the "timestamp" property is not timezone dependent.

The issue here is that the phone can lose the time. For some reason it happens very frequently on Flame, but I suspect it could happen rarely in other phones too, or the time could simply be wrong sometimes (badly configured for example).

What happens in that case: the sent or received message is badly located, and always will be (since the timestamp for a message is frozen).

I've seen other reports for received messages too.

My proposal was to display an in-app message when the most recent message or thread is "in the future" according to the local phone time.

> I thought we always rearrange all the message if there's a time zone change?

We don't, I don't know what makes you think this? What we do is simply changing the displayed date/times according to the timestamp and the new timezone.

Hope this makes sense?

Comment 6

[Jenny Lee]

So..if a message bears a timestamp that is not correct, it will either be placed back in the past conversation or it can appear to be "in the future"? In this case, we can only deal with the ones that's "in the future" by compare it with present local time of the phone? and probably won't be able to do anything about the ones that's in the past?

Based on what I think I understand :p At this point, I don't see a way to perfectly address this issue. All we know is that the message is wrongly placed in the future, and we can do nothing about it... so IMO it's not worth it to inform user about it. 
Do you think it's possible to add an attribute to each message that records the sending order?? and potentially use the order to arrange the messages? Thanks!

Comment 7

[Julien Wajsberg [:julienw] (PTO -> may 13)]

(In reply to Jenny Lee from comment #6)
> So..if a message bears a timestamp that is not correct, it will either be
> placed back in the past conversation or it can appear to be "in the future"?
> In this case, we can only deal with the ones that's "in the future" by
> compare it with present local time of the phone? and probably won't be able
> to do anything about the ones that's in the past?

What I was thinking was quite different: if a message appear to be "in the future", probably the message's timestamp is right but the local time is wrong. That's where I want to display a banner, because in that case the user will think the application is behaving strangely (and it is!).

> 
> Based on what I think I understand :p At this point, I don't see a way to
> perfectly address this issue. All we know is that the message is wrongly
> placed in the future, and we can do nothing about it... so IMO it's not
> worth it to inform user about it. 

As I said, I don't want to inform that a message is wrongly placed, I want to inform that the phone is currently badly configured.

> Do you think it's possible to add an attribute to each message that records
> the sending order?? and potentially use the order to arrange the messages?

I thought of this too but we need to ask Vicamo or Bevis about this. Maybe there are implications in how we receive message.

Comment 8

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

(In reply to Julien Wajsberg [:julienw] from comment #7)
> (In reply to Jenny Lee from comment #6)
> > Do you think it's possible to add an attribute to each message that records
> > the sending order?? and potentially use the order to arrange the messages?
> 
> I thought of this too but we need to ask Vicamo or Bevis about this. Maybe
> there are implications in how we receive message.

We have |message.id|, which is an increasing number [1]. However, in Messaging API draft [2], it's an unique string instead of a number.

[1]: http://mxr.mozilla.org/mozilla-central/source/dom/mobilemessage/interfaces/nsIDOMMozSmsMessage.idl#16
[2]: http://messaging.sysapps.org/

Comment 9

[Jenny Lee]

To think about it, if the system time is wrong, we should handle it from system level ex. showing system notification instead of doing it in message. Unless, the only way we can know local time is wrong is when the sent message is in future time?

Comment 10

[Julien Wajsberg [:julienw] (PTO -> may 13)]

(In reply to Jenny Lee from comment #9)
> To think about it, if the system time is wrong, we should handle it from
> system level ex. showing system notification instead of doing it in message.
> Unless, the only way we can know local time is wrong is when the sent
> message is in future time?

I agree that the ideal way would be to detect this at the System level. However, I don't know if that's easy to do, whereas for us it would be reasonnably easy.

We can also decide to do nothing and just fix the issue in the phone where the time is not right. I just felt that because it was easy to detect in the SMS app, and because the consequences are quite rude, we could inform the user.

Comment 11

[Julien Wajsberg [:julienw] (PTO -> may 13)]

Mass closing of Gaia::SMS bugs. End of an era :(

Comment 12

[Julien Wajsberg [:julienw] (PTO -> may 13)]

Mass closing of Gaia::SMS bugs. End of an era :(