Closed Bug 550022 Opened 15 years ago Closed 14 years ago

Potentially serious data loss from edited draft messages

Categories

(Thunderbird :: Message Compose Window, defect)

Product:
Thunderbird
Component:
Message Compose Window
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 349547

People

(Reporter: cursus.publicus, Unassigned)

Details

(Keywords: dataloss, ue)

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_5_8; en-us) AppleWebKit/531.21.8 (KHTML, like Gecko) Version/4.0.4 Safari/531.21.10 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-GB; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 It is possible to open a message in Drafts in more than one window potentially resulting in serious data loss. After editing a message retrieved from Drafts it is too easy to inadvertently save an unedited version later and hence overwrite the editing. Inexplicably a second selection of a Drafts' message always opens in a new window no matter which option is selected in 'Open messages in'. The problem exists, but is less serious, with other mailboxes when 'Open messages in a new message window' is selected - ie rather than bringing an open message to the front another window with the same message is opened. This can be avoided by selecting 'Open messages in an existing message window' but this is not my preferred setting. In my opinion attempting to open an already open message should ALWAYS bring the existing open message to the front as with all other applications I have used. This would avoid data loss from Drafts and improve the ergonomics of other mailboxes. Reproducible: Always Steps to Reproduce: 1 - Save an unsent message in Drafts. 2 - Open it twice. 3 - Edit one version for an hour. 4 - Save the edited version to Drafts. 5 - Do further work on a crowded screen. 6 - Start closing windows and inadvertently save the, now visible, unedited version to Drafts. 7 - Examine Drafts to discover that only the unedited version exists. I don't use Tabs.
(In reply to comment #0) > In my opinion attempting to open an already open message should ALWAYS bring > the existing open message to the front as with all other applications I have > used. This would avoid data loss from Drafts and improve the ergonomics of > other mailboxes. I think this should be the major focus of this bug, and as such, I suggest changing the summary to reflect that. (If you do that, please also remove the dataloss keyword and change the Severity field to Enhancement; this _can_ cause dataloss, but it's rather a side issue: even *saving* can cause dataloss.)
Component: General → Toolbars and Tabs
Keywords: dataloss, ue
OS: Mac OS X → All
QA Contact: general → toolbars-tabs
Hardware: PowerPC → All
this is a duplicate
Whiteboard: dupme
> 2 - Open it twice. (1) A reoprt of real problem is bug 400043 which is for special case - UIDPLUS is supported but UID is not returned correctly. (2) Same problem(delete saved draft each other) can occur, if UIDPLUS is not supported by IMAP server, because (a) old draft version to be deleted is searched by message-id:, (b) same message-id is used by multiple compose windows for single draft mail, (c) message-id during composing is not changed. (3) As for local Drafts folder, loss of saved draft won't occur, because "old draft version to be deleted" is determined by unique offset value in local folder. (2) is easily be re prouced by simple/intentional test. AFAIR, potential "saved draft loss" of (2) is already known in other bug. But I don't remember that bug was for the potential "saved draft loss" issue or for other draft related issue. To Neville Hillyer(bug opener): IMAP case? Local Drafts folder case? If local Drafts folder case, what is detiled steps to produce problem reliably?
I am POP only with no facilities for testing IMAP. My latest setup has no Local Folders: user_pref("mail.accountmanager.localfoldersserver", "server1") where server1 is my only server except for smart mailboxes (sever2). However, I have again examined my test account with default POP settings and, as far as I can tell, a second version is saved in Drafts, as you describe, if set to use main account Drafts but not if set to use Local Drafts. Whilst this is still unsatisfactory it probably explains the behaviour of my non-standard setup. The steps to reproduce are as originally described but with main account set to use Drafts folder on Local. In my opinion it would be more satisfactory to resolve the underlying problem, ie attempting to open an already open message should ALWAYS bring the existing open message to the front rather than open another window.
Are you talking about next(known) problem? If all other windows(main Tb window) except compose window(s) is closed, drafat cannot be saved, even after re-open of main Tb window?
Bug I mentioned is bug 530779, but it sounds IMAP only. Drafts of Local Folders is also affected?
I don't see what bug 530779 has to do with this. And as far as I know the general problem of being able to do multiple drafts for a single message exists for all account types. And that goes for other "multiple drafts" issues. Here is a solid query for "draft save" bugs which anyone can pour through to find common issues http://bit.ly/aDeo2C - and maybe even bring some organization to the list. (bonus if you find the cause of bug 482836) I don't know if it's in that list, but I'm absolutely certain there is a bug that specifically requests not allowing multiple edits on the same draft.
Component: Toolbars and Tabs → Message Compose Window
QA Contact: toolbars-tabs → message-compose
> Are you talking about next(known) problem? I don't understand the question above. > If all other windows(main Tb window) except compose window(s) is closed, drafat cannot be saved, even after re-open of main Tb window? I think you are mistaken. I can open a message from Drafts, close all other windows, edit the message and save the edits to the Drafts folder - overwrites unedited version as usual.
(In reply to comment #7) > I don't know if it's in that list, but I'm absolutely certain there is a bug > that specifically requests not allowing multiple edits on the same draft. Bug 321355 sounds like what you're talking about; Neville, want to mark this bug a duplicate?
I don't know much about this bug reporting process but whilst it does appear to be a duplicate I have these concerns: 1 - Bug 321355 was reported in 2005 (with a few later updates) but despite apparent agreement about the severity little appears to have been done to fix it. 2 - There is much more information on this page especially: Local/other folder differences and the view that it would be more satisfactory to resolve the underlying problem, ie attempting to open an already open message should ALWAYS bring the existing open message to the front rather than open another window. Can somebody with more experience advise upon the best action to take?
Neville Hillyer, are you talking about next phenomenon? (only case of "real draft loss in local folder") 1. a draft exist in local mail folder (say V-0) 2. edit the draft -> compose window 1 (W-a) 3. edit the draft -> compose window 2 (W-b) 4. At W-a : save as draft(or aut-save) -> V-0 is deleted, V-1a is saved 5. At W-b : cancel, close without update, ... -> V-0 is lost Note: If draft is updated and saved at W-b too, "V-0 is already deleted" won't produce any problem, and new version of V-1b is saved. In this case, W-a and W-b wont't delete saved draft each other if local mail folder. So I said "no data loss" in local folder case.
In all previous tests I hit red button (top left of OS X window - probably same as X button on Windows/Linux) and then selected Save from popup. Replace your 4 & 5 with above and change end of 5 to V-1a overwritten by V-1b resulting in loss of V-1a data. As previously established this appears to only affect Local Drafts and not Drafts on other accounts UNLESS another account and Local have been combined by non-standard, but otherwise very effective, actions. It is worth remembering that users are invited to opt for a global (Local) Inbox and many will also opt to do the same for Drafts etc. I am afraid I don't understand your note. I wonder if I should start a separate bug for the more widespread issue of multiple windows with identical content.
(In reply to comment #12) > Replace your 4 & 5 with above and change end of 5 to V-1a overwritten by V-1b > resulting in loss of V-1a data. I could reproduce such problem, with local mail folder(local mail folder only problem). For ease of explanation, mail data length=10. Subject Order Received (0) Initial V-00 0 (1) Edit-1=>W1 (current draft = mail at offset=0) (2) Edit-2=>W2 (current draft = mail at offset=0) (3) W1: Save V-1a V-1a 10 (V-00 at offset=0 is deleted) (4) Compact folder V-1a 0 (5) W2: Save V-1b V-1b 10 (previous version for W2 = mail at offset=0) W2 thinks V-00==mail at offset=0, so V-1a at offset=0 is deleted. This is local mail folder only problem. If V-00(previous version of draft) is not mail of offset=0 (say offset=X), data start from offset=X after compact is not proper mail data(a part of other draft mail). So delete of V-00 won't happen (although probability of "delete of mail at offset=X" is not absolutely ZERO), and phenomenon becomes "previous version of draft is not deleted". By the way, SeaMonkey 2.0.2 changed Message-Id: upon each draft save to IMAP folder. So problem (2) in Comment 3(delete saved draft each other if IMAP) won't occur with Seamonkey.
Possible solution of above problem. - Change Message-ID: upon "Edit Draft" and each draft save - Check Message-ID: of previous version before delete
Offset=0 of draft mail was not required condition, and victim was not always new version of draft at other window. (0) Drafts folder: (No deleted mail exists before offset=X of mail-N-V-00) mail-1 offset=0 | mail-(N-1) offset=(X-Lm) mail length=Lm mail-N-V-00 offset=X mail length=Ln mail-(N+1) offset=(X+Ln) (1) W-a : Edit mail-N-V-00 (current draft = mail at offset=X) (2) W-b : Edit mail-N-V-00 (current draft = mail at offset=X) (3) W-a : Save mail-N-V-1a. Appended to last of Drafts. mail-N-V-00 at offset=X is deleted (4) Compact folder. mail-(N+1) is placed at offset=X (5) W-b : Save mail-N-V-1b. Appended to last of Drafts. W-b thinks V-00==mail at offset=X, so mail-(N+1) at offset=X is deleted. If mail-N-V-00 was last mail in Drasts, mail-N-V-1a is deleted. If auto-compact is enabled, Drafts is usually already compacted. So, mail data of offset-X after compact at step (4) is usually valid mail data(next mail). And, if W-b is kept open for long time, compact of Drafts(initiated by auto-compact for other folder) usually happens while W-b is open. Probability of "loss of a draft" is higher than I thought initially.
Neville Hillyer(bug opner): Can you check "auto-compact" is relevant to your case or not? (1) set mail.purge.ask=true, and restart Tb(mandatory) (2) During step 5 in your comment #0, (2-a) OK to first dialog before start of auto-compact during step 5. (never check "Do this automatically...") If dialog appeared multiple times, reply OK to all dialogs. After end of compactions, go to step 6. (2-b) Cancel(or NO) to all dialogs before start of auto-compact. (never check "Do this automatically...") After a while, go to step 6.
(also no lack of drafts+dataloss bugs http://bit.ly/dBFIwi )
After updating to TB 3.0.3 I attempted comment 16 instructions on my combined Local/main account TB. Despite waiting an hour I never got an auto-compact dialog - what should invoke this? What is your objection to changing TB to ensure that messages can only be opened once as previously described.
(In reply to comment #18) > What is your objection to changing TB to ensure that messages can only be > opened once as previously described. I'm not opposite to a solution of "prohibit multiple open of a draft". Problem of my comment #15/#16 is: (A) If a draft is opened by multiple compose window concurrently, (B) And if "save as draft"(==delete of original) occurs on a window, (C) And if "compaction of Drafts folder" occurs after (B), (D) upon save of draft(=try to delete previous version) at a compose window, (E) Tb deletes other draft mail in Drafts folder. When (A)==false, problem wont't occur, so your proposal is correct. When (C)==false, problem wont't occur, so "disable compact of Drafts while editing draft" also can be a solution. I merely presented a way to make (E)==false directly. But, essential cause of the problem is not "multiple compose window for a draft mail". (0) Drafts folder: mail-1-V-00 offset= 0 mail length=1000 mail-2-V-00 offset=1000 mail length=1000 mail-3 offset=2000 mail length=any (1) W-1 : Edit mail-1-V-00 (current draft = mail at offset=0) (2) W-2 : Edit mail-2-V-00 (current draft = mail at offset=1000) (3) W-1 : Save mail-1-V-01. Appended to last of Drafts. mail-1-V-00 at offset=0 is deleted (4) Compact folder. mail-3 is placed at offset=1000 (5) W-2 : Save mail-2-V-01. Appended to last of Drafts. W-2 thinks V-00==mail at offset=1000, so mail-3 at offset=1000 is deleted. If mail-2-V-00 was last mail in Drasts, mail-1-V-01 is deleted. Problem is: When a compose window thinks previous version is offset=X, if compact occurs and data at offset=X becomes a valid mail, (not a part of other mail. starts with From -..., X-Moxilla-Staus:,...) "save as draft" at compose window deletes other mail at offset=X. In order to resolve problem in above very rare case(multiple drafts of same length are edited concurrently), "to make (E)==false" is required. When "multiple compose window for single draft mail", condition of "multiple drafts of same length are edited concurrently" always happens.
(In reply to comment #18) > Despite waiting an hour I never got an auto-compact dialog - what should invoke this? It's not surprizing; - if you don't enable auto-compact. - if you enable auto-compact, mail.purge.ask was false, you changed mail.purge.ask to true, but you didn't restart Tb. - if you enable auto-compact and mail.purge.ask=true, but auto-campaction didn't occur because no folder reached threshold. Which case? If you don't enable auto-compact and you never manually executed compaction of Drafts(or File/Compact Folders), your problem is different from my comment #15/comment #16/comment #19.
I am getting lost with this bug process and would be grateful if somebody could advise upon its status.
What is the status of this bug?
Neville, I see it says "Unconfirmed" at the top, so I assume that no one has decided that the bug is anything yet. Some of these problems take many years to find and then to decide on creating a solution or leaving it to get worked out by the application of extensions. I just ran across another Drafts issue my self, but it is a little different than yours. Good luck with yours.
Neville, the status, I think, is there's multiple questions for you to answer in comment 20.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
Whiteboard: dupme → [waiting for response to comment 20][dupeme?]
This was a long time ago. As I said in comment 18 I did my best to follow your instructions. It was on a test account not used for anything else. Would it need to be an active account to behave as you expected? If necessary I am happy to install a new test account and try it again but I would like precise instructions.
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
OK, bug 349547 describes this and is confirmed
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → DUPLICATE
Whiteboard: [waiting for response to comment 20][dupeme?]
It appears to be. It also appears to affect all platforms. I am not sure why none of us found this much earlier bug report. Since this bug results in data loss I hope somebody will work on it.
You need to log in before you can comment on or make changes to this bug.