In the message app, threadId is different between sms/mms , which should be the same no matter what message type is. In the system message callback, message threadId even become undefined in this scenario.
Hi Steve, Two questions: 1. Does you gecko already include Bug 865157? 2. How do you reproduce this bug? Are you trying to receive one SMS and one MMS from the same sender? Thanks for your reply in advance.
One more question: 3. Did you use the central or b2g18?
One more question: 4. So you're saying the thread IDs (in system message) of MMS and SMS are numbers but not different? Or the one of MMS is undefined but the one of SMS is a number?
Created attachment 747844 [details] [diff] [review] Patch I believe this is exactly the root cause because the thread IDs of SMS and MMS are the same when the messages came from the same sender. However, I won't land this until Steve confirms this. In this patch, I also correct the timestamp in system message, which should be a Date object and consistent with the DOM message events. No worries about the compatibility issue with Gaia because they haven't used it yet.
Attachment #747844 - Flags: review?(vyang)
(In reply to Gene Lian [:gene] from comment #1) > Hi Steve, > > Two questions: > > 1. Does you gecko already include Bug 865157? I've tested it on both latest central and b2g18, I believe it should be in central at least > 2. How do you reproduce this bug? Are you trying to receive one SMS and one > MMS from the same sender? Yes, I tried to receive sms/mms from same number, but threadId became undefined in system message and the number is still way different from sms threadId in message received event. > > Thanks for your reply in advance. about 4. MMS is undefined but the one of SMS is a number while in system message.
(In reply to Steve Chung from comment #5) > Yes, I tried to receive sms/mms from same number, but threadId became > undefined in system message and the number is still way different from sms > threadId in message received event. OK. Let me double check. You are saying the thread IDs in SMS and MMS' received events are still different (but they are both valid IDs)? However, I cannot reproduce this one... Note that for MMS, sometimes the first received event would belong to a separate thread because the sender of the first notification is determined by carrier (like "1"). The second received event will then has the right thread consistent with the one of SMS. > about 4. MMS is undefined but the one of SMS is a number while in system > message. OK. I've fixed this one in my patch, but the thread IDs in the received events are still not consistent, as mentioned above. However I cannot reproduce that.
Comment on attachment 747844 [details] [diff] [review] Patch Review of attachment 747844 [details] [diff] [review]: ----------------------------------------------------------------- We can land this first, and file another bug to reproduce the other problem.
Attachment #747844 - Flags: review?(vyang) → review+
Whiteboard: [NO_UPLIFT] → [NO_UPLIFT] [fixed-in-birch]
Hi Anshul, We need your help to de-marked [NO_UPLIFIT]. This patch is basically changing the content of system message fired when receiving an SMS or MMS. It doesn't affect any interfaces to be called by RIL but the QC-RIL might need to adjust the content of system message broadcasting for SMS (the timestamp should be returned as a Date object instead of a number so that it can be consistent with the event). Please let me know if you have any questions. Thanks!
Thanks Anshul for the quick help. :)
Blocking as it is part of MMS/SMS requirement
blocking-b2g: leo? → leo+
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla23
status-b2g18: --- → fixed
status-b2g18-v1.0.0: --- → wontfix
status-b2g18-v1.0.1: --- → wontfix
status-firefox21: --- → wontfix
status-firefox22: --- → wontfix
status-firefox23: --- → fixed
You need to log in before you can comment on or make changes to this bug.