(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?

(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.

(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'.

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...

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.

(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. :)

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.

(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

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.