Closed Bug 1024835 Opened 10 years ago Closed 7 years ago

[MMS] Receiver receive a garbage message when receiving a MMS if turn off auto retrieve mode

Categories

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

Product:
Firefox OS Graveyard
Component:
Gaia::SMS
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-b2g:-)

Status:
RESOLVED WONTFIX
Project Flags:
blocking-b2g -

People

(Reporter: ashiue, Unassigned)

References

Details

(Whiteboard: [p=2])

Attachments

(2 files)

message_auto_retrieve_off.mp4
4.92 MB, video/mp4
Details
disable_auto_retrieve.log
533.86 KB, text/x-log
Details 
Gaia      a3a5322692578e0a577fb7fa08e32144b2b05ba3
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/0293597de41f
BuildID   20140612160201
Version   32.0a2


STR:
1. Turn off auto retrieve in Messaging Settings 
2. Test device receive a MMS message

Expected result:
Test device receive the download request message in the sender phone number conversation

Actual result:
1. Test device receive the download requested message in title "1" conversation
2. After downloading the attached file, the "1" message conversation still exist
Can you please turn on the RIL debugging pref and capture a logcat while this is happening?
Flags: needinfo?(ashiue)
Hi, please refer this log.
Flags: needinfo?(ashiue)
Hey Bevis, does that make sense to you ?
Flags: needinfo?(btseng)
(In reply to ashiue from comment #0)
> Actual result:
> 1. Test device receive the download requested message in title "1" conversation
It's normal because the address of the MmsNotification is set to "1" according to the log.
> 2. After downloading the attached file, the "1" message conversation still exist
I can reproduce this with my local carrier SIM (CHT).
I found that this symptom will be disappeared if I reboot the device or kill the sms app.
I also reviewed current implementation, the DB shall be updated before MmsService notifies the new received message to the apps.

Is there something cached in the sms app that cause this this empty thread still displayed in the thread list?
Flags: needinfo?(btseng) → needinfo?(felash)
(In reply to Bevis Tseng [:bevistseng] (btseng@mozilla.com) from comment #4)
> (In reply to ashiue from comment #0)
> > Actual result:
> > 1. Test device receive the download requested message in title "1" conversation
> It's normal because the address of the MmsNotification is set to "1"
> according to the log.
> > 2. After downloading the attached file, the "1" message conversation still exist
> I can reproduce this with my local carrier SIM (CHT).
> I found that this symptom will be disappeared if I reboot the device or kill
> the sms app.
> I also reviewed current implementation, the DB shall be updated before
> MmsService notifies the new received message to the apps.

So, is this a bug in RIL?

> 
> Is there something cached in the sms app that cause this this empty thread
> still displayed in the thread list?

yeah, we don't refresh the list and instead try to change it according to events. As a result we never remove anything currently, unless the user deletes a message or thread himself.
Flags: needinfo?(felash)
When we retrieve a MMS, we change the not-downloaded MMS by the retrieved MMS, but the current logic works only if it's in the same thread.

Is it the issue here?
Flags: needinfo?(btseng)
(In reply to Julien Wajsberg [:julienw] from comment #6)
> When we retrieve a MMS, we change the not-downloaded MMS by the retrieved
> MMS, but the current logic works only if it's in the same thread.
> 
> Is it the issue here?

I think so. 
From the result#1, the thread of the mms notification is not the same to the thread of the downloaded mms message because the address from MMSC is just a dummy address '1'.
Flags: needinfo?(btseng)
Ok, then we'd need to get the thread from the message (I think we have the information in the Threads object) so that we can refresh it.
blocking-b2g: --- → 2.0?
It's probably made more apparent by bug 927783 (before that bug, we were refreshing the whole thread list when we displayed it, so I think the bad thread was removed).

Bevis, do you know if the sms-deleted event from bug 1023695 would be sent in the case we have here? I'd say it would not...
Blocks: 927783
Flags: needinfo?(btseng)
QA Wanted to do branch checks.
Keywords: qawanted
QA: note that the bug appears only with some carriers (that sends the MMS download notification with a different number than the "real" number). For example, this doesn't happen with mine, but this happens with Bevis' carrier.

So please check that you reproduce the issue locally first.
triage: let's wait for more information to see if we should block it. is it regression on other branches/carrier
(In reply to Julien Wajsberg [:julienw] from comment #9)
> It's probably made more apparent by bug 927783 (before that bug, we were
> refreshing the whole thread list when we displayed it, so I think the bad
> thread was removed).
> 
> Bevis, do you know if the sms-deleted event from bug 1023695 would be sent
> in the case we have here? I'd say it would not...

Hi Julien,

Yes, it will be sent in this case as well because in fact, the thread will be removed after message is updated.
Hope bug 1023695 is also helpful to fix this problem. :)
Flags: needinfo?(btseng)
Bevis, but in this case, the message itself is not deleted since it has the same id? It will be confusing if sms-deleted is sent in this case?
Flags: needinfo?(btseng)
My original purpose is to notify any deleted change in the mobile db.
In this case, the received ondeleted() event only contains the id of the removed thread.
This is different from the scenario of deleting message where the event shall contain the id of removed messages.
Flags: needinfo?(btseng)
ok. This does not look very consistent to me (we have no message when we create a thread for example), but why not.
Blocks: sms-sprint-2.0S6
Whiteboard: [p=2]
Target Milestone: --- → 2.0 S6 (18july)
The carriers available to us do not reproduce this bug even on the build in comment 0.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA-Wanted / QAnalysts are not able to reproduce this issue. Not closing as WFM as this may be SIM-dependent
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
I'd recommand +ing it, especially that we'll use most of the work here to fix bug 1022575 later.
Alison - Can you check if this happens on 1.4 Flame?
Flags: needinfo?(ashiue)
Tried on
Gaia      d1cf95dc5e8b2f52148487291318542f1396608e
Gecko     https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/a8bb6b76696b
BuildID   20140611000202
Version   30.0

with local carrier SIM (CHT) also reproduced this issue.
Flags: needinfo?(ashiue)
From all the comments I see currently only Taiwanese local carrier (CHT) SIM can reproduce.
I'll leave the nomination for now and see if any other SIM has the same issue.
(In reply to Wesley Huang [:wesley_huang] from comment #22)
> From all the comments I see currently only Taiwanese local carrier (CHT) SIM
> can reproduce.
> I'll leave the nomination for now and see if any other SIM has the same
> issue.

QA was not able to reproduce this on any other SIM and this is not a regression. We can take an low risk patch if available
blocking-b2g: 2.0? → -
To whoever will take this bug: given it's not a blocker, we should divide the work here in 2 parts: one part that does the common work for this bug and 2.0+ bug 1022575 (possibly in a separate bug), and one for the specific work in this bug.
Removing it from sprint 2.0S6 since it's not blocker anymore...
No longer blocks: sms-sprint-2.0S6
Target Milestone: 2.0 S6 (18july) → ---
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Mass closing of Gaia::SMS bugs. End of an era :(
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Mass closing of Gaia::SMS bugs. End of an era :(
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: