1. Title : Receiving a new sms during delete operation is deleting the newly received sms thread 2. Precondition : Messageing app should be working. 3. Tester's Action : Message - Edit icon - Select all - delete - receive new sms - Select cancel in confirmation dialog - the newly received sms thread is unchecked - perform delete operation 4. Detailed Symptom (ENG.): The newly received sms thread also getting deleted. 5. Expected : The newly received sms thread should not be deleted in the thread_list when we perform delete operation. 6.Reproducibility: Y 1)Frequency Rate : 100% 7.User cannot check the new sms received. 8.Gaia Revision: 8e7262e3d98ea9574d7f79c1e890ad80cfa40c27

Bug 860607 seems related.

I could not reproduce this issue. Need qa's help for investigation.

ni? reporter - description is 100% occurrence, can you confirm this and where possible provide some logs in parallel?

use leo device, gaia: e7e338a765e22334b40ced41489a785941382c66 (4/10) can't reproduce the issue

Please check the attached log for Delete operation.

Please check the video which is deleting the thread even when the particular thread is deselected

This issue depends on Bug:857942 The proposed patch fixes the delete problem issue also. Please review the proposed patch in that issue and provide your comments.

leo nom again - internal QA cannot reproduce this bug.

James: I think the bug happens when you delete a thread where you receive a SMS. I think we don't want to delete this newly-received yet-unread SMS.

Hi Julienw, The patch is for when we are deleting the thread_list and if we received a new sms the newly received sms thread also deleting even when it is deselcted. The map() function which is existing in the thread_list_ui.js is not working. The master code having some problems to check the operation.So i have done the changes according to the master code but i am not able to test it. please review the patch and provide your comments. Thanks,

Sorry, I fail to see how this patch fixes the bug you want to fix. More over, the call to "map" works for me, so I think this patch is wrong. I don't have a magic idea to fix this properly though. My best proposition would be to warn the user if the thread has unread messages in that thread. The other possibility is : 1. when we go in "edit mode" (or "delete mode"), fetch all id for all threads 2. if one thread is selected, we should delete only those messages that were already there when we triggered the edit mode. I feel like the first step is a no-go because it would be a performance drain. Hence my first "best" proposition. Ayman, what do you think of this ?

borja, any thought ?

Hi Julienw, The deleting operation is working fine if we go to particular thread and perform delete. But if we are in thread_list and consider we receive an sms for the thread which is already existing in thread_list. Steps: 1.Open SMS 2.Select all the threads and click on delete. 3.At the pop-up screen of delete,receive new sms from the number which is already existing in the thread_list. 4.If we go back to thread_list screen,we can see that the particular thread where sms received is deselected. 5.If we perform Delete operation the deselected sms thread also getting deleted. Thanks, Leo

ok, so, this bug was absolutely not about what I thought at first. I thought you didn't want to delete a thread where we might receive a SMS. I'll file a new bug about what I proposed in comment 12 and review this again with this new information.

Hi there, Probably we would need the delete method with ThreadID filter in order to avoid this type of behaviours. Vicamo, Could you confirm us if all features related with ThreadID are available? Thanks!

I filed Bug 864790 about warning the user if we're about to delete unread messages. Now, about this bug, it seems to me the only problem is that when we're in edit mode and we receive a message from a thread that we already selected to delete, the thread is unselected. The fix is not so easy because the logic is (incorrectly) spread between MessageManager.onMessageReceived ans ThreadListUI.appendThread. So here are the tasks necessary to resolve this : * move the ThreadListUI-specific code that is in MessageManager.onMessageReceived to a new function ThreadListUI.onMessageReceived, and call it from MessageManager.onMessageReceived. * probably add a new argument in ThreadListUI.appendThread that would define if the new thread is in the checked or unchecked state. This state will be either used in appendThread to update threadDOM, or passed to createThread to have it created correctly in the first place. Please prepare a patch with these changes and I'll review it. Thanks !

Borja, this has nothing to do with this. Here the problem is that we remove the thread and add another one and so, it is unchecked by default. Hence the inconsistency. That's all.

I thin that it could be even easier. If we are removing from UI all 'Threads' while deleting through API using ThreadID (This gap-time it's gonna be reduce a lot), if we receive a new message the Thread it's gonna be created properly through 'onMessageReceived' taking into account the flag 'edit' (we have to modify this). Wdyt?

borja: that won't resolve the bug... because you'll still delete the messages in that thread id, even if a new one has come. Actually, I think there are 2 possible solutions : * either do what I suggested in Comment 17. This results in having an unread message deleted, but resolving Bug 864790 would make this ok. * or uncheck the thread where there is a new message (that's what's done now), but then, we must not delete it (and we're deleting it now). Maybe Ayman can give us his preference here.

Hi, Issue is not reproducible in AU071 version. Thanks, Leo

Leo, either you're talking about another issue, either you're not trying in the correct way. The issue happens if you receive a SMS while the confirm box is displayed.

Hi Julienw, I have tested the same issue. Steps: 1.Select all the threads and click on delete . 2.At the pop-up screen of delete,receive new sms from the number which is already existing in the thread_list. 3.perform delete operation. Result: The newly received sms thread which is deselected is not deleting.

ok so maybe Bug 857942 fixed it, but it is not in v1-train nor v1.0.1. Leo, which gaia branch did you use ?

Hi Julien, What you are saying is correct.Bug 857942 fixes this issue. I have applied that patch and tested. Bug 857942 is merged in master rite? Thanks,

yep it's in master. I'll dupe this one to that one then.