778065 - With system/TB slowed down, after triggering "Empty Junk", if user quickly selects another folder, messages of that other folder will be purged

Status: UNCONFIRMED

(SeaMonkey :: MailNews: General, defect)

Description

[jacques jamain]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120715 Firefox/14.0.1 SeaMonkey/2.11
Build ID: 20120715041107

Steps to reproduce:

when selecting a subfolder for emptying, if for any reason (cpu load for instance) you can select an other subfolder in an other account  before the former cleaning was done  then it is that last selected subfolder which is cleared...


Actual results:

the wrong subfolder has been cleared


Expected results:

selecting a new subfolder should not be allowed when the previous action is not finished

Comment 1

[Wayne Mery (:wsmwk)]

I'm pretty sure this has a counterpart in Thunderbird. Though I'm not sure we'd call it an outright dupe

Comment 2

[Thomas D. (:thomas8)]

Jacques, can you provide more details how you "clear" the folders?
Is this about *deleting* subfolders from the folder tree?
Are you using DEL key to delete? Or menus? Which?
Can you provide more detailed instruction (steps to reproduce) what exactly you did to see this bug? Every key press or mouse click matters, and their exact sequence.

Comment 3

[jacques jamain]

(I'm working with the French version  and I'm not absolutely sure of the item names translation)
For instance, for a given account I select the junk folder to be emptied: right mouse click to select and then left click to request the clear action. In some circumstances while the clearing action is being performed I can now select an other folder in an other account and it could happen that this last folder is cleared (I got that also with an other account name selected, the account folders then disappear!!! - xxx and xxx.msf files deleted in the profile\mail\account).
This behaviour is visible as the messages of the folder you asked to clear are always displayed while you can select the other folder (or account).
As previously said this happens in heavy system load (or browser load).

Comment 4

[Thomas D. (:thomas8)]

I understand that reporter clicks on "Empty Junk" from context menu of Junk folder, then somehow before (or while?) that command is actually triggered internally (with command handling slowed down by heavy system/browser workload), user manages to select another folder, and SeaMonkey then wrongly establishes that the last selected folder is the "currently selected" folder for "Empty Junk" operation, and stubbornly proceeds with deleting all messages from an entirely unrelated folder.

Comment 5

[Thomas D. (:thomas8)]

(In reply to Wayne Mery (:wsmwk) from comment #1)
> I'm pretty sure this has a counterpart in Thunderbird. Though I'm not sure
> we'd call it an outright dupe

I'm sure that this also happens in TB if it happens in SeaMonkey.
Couldn't find duplicates.

Comment 6

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #4)
Based on my understanding, adjusting summary. Feel free to change if I'm wrong.

Comment 7

[Tony Mechelynck [:tonymec]]

This sounds like a MailNews Core bug but in the absence of a Thunderbird case I'd like some MailNews developer to have a look. (Mnyromyr?)

Also, SeaMonkey 2.11 is obsolete by now. Has anyone observed this bug in SeaMonkey 2.17 or later, in Thunderbird 17.0.5 or later? I suppose so, but a confirmation would be nice.

Comment 8

[jacques jamain]

I saw that recently with SeaMonkey 2.17...

Comment 9

[Thomas D. (:thomas8)]

(In reply to Tony Mechelynck [:tonymec] from comment #7)
> This sounds like a MailNews Core bug but in the absence of a Thunderbird
> case I'd like some MailNews developer to have a look. (Mnyromyr?)

^^

Comment 10

[Rainer Bielefeld]

Still anybody able to reproduce the problem?

Comment 11

[Rainer Bielefeld]

Never confirmed by a second user, No response, so I close this one for now.
@Reporter: Please feel free to reopen this Bug if you still can reproduce the problem with a current SeaMonkey version and a current OS and if you can contribute a step by step instruction due to <https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines>  (containing every key press and every mouse click) how to reproduce the problem reliably.

Comment 12

[Thomas D. (:thomas8)]

(In reply to Rainer Bielefeld from comment #11)
> Never confirmed by a second user, No response, so I close this one for now.
> @Reporter: Please feel free to reopen this Bug if you still can reproduce
> the problem with a current SeaMonkey version and a current OS and if you can
> contribute a step by step instruction due to
> <https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines>
> (containing every key press and every mouse click) how to reproduce the
> problem reliably.

Rainer, with or without sufficient information, this is too serious to be closed without systematic examination by developers.

Reporter initially replied to our requests for information, from which we have tentative STR in comment 4. I guess the problem is how to create the "heavy system load" condition for reproduction.
But an experienced coder might also be able to find this bug by code analysis.

E.g., we must indeed ensure that after hitting commands like "Delete folder", "Empty trash" etc., there's not even the slightest theoretical possibility that user can change the folder before the actual delete commands gets the "selected folder". Iow, instead of getting the selected folder lateron, we must ensure that the command already has the full URL of the folder when it is triggered, or something like that.

Please note that this bug is also waiting for response by mnyromyr, and TB QA (Wayne and I) is also interested and Wayne has even hinted in comment 1 that he believes there must be a corresponding TB bug.

Comment 13

[Thomas D. (:thomas8)]

Plus, comment 8 DOES have confirmation of the bug by a second person.

Comment 14

[Wayne Mery (:wsmwk)]

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #13)
> Plus, comment 8 DOES have confirmation of the bug by a second person.

Unfortunately comment 8 is exceedingly old, from the user who was NI and has not replied for 4 months.

FWIW, ISTR there was a thunderbird bug like this that was closed WFM

(Mnyromyr also hasn't relied, so removing NI)