Closed Bug 373270 Opened 18 years ago Closed 18 years ago

Running Junk Mail Controls on Folder then Switch Folders Causes Data Loss

Categories

(Thunderbird :: General, defect)

defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird2.0

People

(Reporter: mscott, Assigned: mscott)

References

(Blocks 1 open bug)

Details

(Keywords: dataloss, verified1.8.1.3)

Attachments

(2 files)

Trunk and branch builds. 1) Run Junk mail controls on a folder A. 2) While we are analyzing messages, load folder B in the same 3-pane. 3) When we are done analyzing folder A, the junk actions are actually applied to messages in folder B. So msgs in folder B may get marked as read, and moved to the junk folder even though they aren't junk. The current classifier that analyzes a folder keeps track of message view indices, and when you change a folder the view gets swapped out from underneath it and it ends up applying the commands to the view indices in folder B.
Flags: blocking-thunderbird2+
Attached patch the fix (deleted) — Splinter Review
This patch does the following: * determineActionsForJunkMsgs now acts on a folder instead of a view and uses the folder to get the spam settings. * performActionsOnJunkMsgs now takes a folder an an nsISupportsArray of msgHdrs. We directly mark the message as read on the folder and go through the copy service to perform a move if we have a junk folder to move the messages to. * gMessageClassificator is no longer a global object that gets re-used. We now create a message classifier every time we run the junk mail controls on a folder. As a result, we don't have to worry about the classification state getting zeroed out by a subsequent call. * gMessageClassificator::init has gone away. We now use a constructor to initialize the state variables for our classifier. * Kep track of the message header for each messageURI we've asked to be analyzed. * For each message analyzed as Junk, add the msg hdr to an nsISupportsArray of hdrs. We'll use this list when performing the junk actions on the messages. So far this is working well. I can move to another folder and messages from the original folder get marked as junk and moved to my junk folder. The undo operation to undo the move still works.
Attachment #257909 - Flags: superreview?(bienvenu)
Attachment #257909 - Flags: superreview?(bienvenu) → superreview+
This is fixed on the trunk, porting this to the branch is going to be much harder than I thought, it looks like this code changed drastically on the trunk leaving the trunk patch useless for the branch :)
Attached patch port the patch to the branch (deleted) — Splinter Review
In order to port this to the branch, I found it much easier to merge Jens patch for Bug 253234 to the branch first.
Comment on attachment 257993 [details] [diff] [review] port the patch to the branch branch port, includes changes from Bug 253234 which made the trunk patch apply cleanly. I thought that was less risky than re-writing the patch.
Attachment #257993 - Flags: superreview?(bienvenu)
Severity: normal → critical
Keywords: dataloss
OS: Windows XP → All
Hardware: PC → All
Attachment #257993 - Flags: superreview?(bienvenu) → superreview+
Status: NEW → RESOLVED
Closed: 18 years ago
Keywords: fixed1.8.1.3
Resolution: --- → FIXED
Blocks: TB2SM
verified fixed on 1.8.1.3 on Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.0 ID:2007032620- i have tested with the steps to reproduce from comment#0 and can confirm this bug as fixed.
(In reply to comment #4) > (From update of attachment 257993 [details] [diff] [review]) > branch port, includes changes from Bug 253234 which made the trunk patch apply This patch broke some context menus that depended on analyzeMessagesForJunk(). This affects Thunderbird 2.0 in MOZILLA_1_8_BRANCH (Bug 377113). (According to the comments of Bug 324953, the same problem also affects branch Seamonkey and trunk Tb and Sm.)
Depends on: 377113
No longer blocks: TB2SM
Blocks: TB2SM
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: