User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050903 Firefox/1.6a1 Build Identifier: version 1.6a1 (20050902) when a message that was autosaved was canceled (by closing compose window and choosing "dont save" option on the popup), the autosaved draft remains in the drafts folder. This is a privacy, security and diskspace concern. There should be a way for the user to cancel composition without having to worry about messages being left on disk or taking up space. Reproducible: Always Steps to Reproduce: 1. Compose a new message but instead of sending, close the compose window 2. Choose "dont save" in the popup that results 3. Think that the message is not saved and no record of it anywhere Actual Results: The autosaved message still exists in the drafts folder even though no explicit save was intended for later compsing. The user intended to cancel the composition, but ends up with the message being saved permanently. Expected Results: It should have removed the auto-save draft once the its task of providing backup for compose was done and user intended to cancel without saving.

*** Bug 308870 has been marked as a duplicate of this bug. ***

Confirming. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051026 Thunderbird/1.5 ID:2005102604 Also, if the message have not changed since the last autosave there is no confirmation dialog (with choises to save or cancel) .

Upgrading priority to normal as this could have potential security implications too. I found a bunch of old emails in my drafts which I did not save there intentionally and which should not have been recorded. Also I get confused as to which ones from among the drafts list I intentionally saved as drafts for later sending and which ones are ghost drafts, if there are several versions.

still present in 1.5rc2, version 1.5 (20051201)

The autosaved message also remains if I send a normal message.

See also bug 314009

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1) Gecko/20060919 SeaMonkey/1.1b] (nightly) (W98SE) Confirming, with SeaMonkey.

TB also of course from a work standpoint this is a major problem. If one has many, many works in progress and legitimate drafts, then this bug makes it difficult to determine and impossible trust what work in the drafts folder is and is not finished. (the only way to keep drafts folder clean is delete the draft immediately after canceling - which requires one to know the bug exists)

blockingTB2? == this is a major problem for people who use drafts a lot, lots of junk is left in the drafts folder, see comment 8

*** Bug 363567 has been marked as a duplicate of this bug. ***

I'm getting this as well. The drafts box is full of multiple copies of draft emails. Danger of using the wrong one, and also very messy. Also, when an email is sent, the draft is left in the draft box. Expected behaviour: 1 - Draft is first auto-saved after specified time 2 - Later auto-saves overwrite the previous (current behaviour adds multiple revisions) 3 - When email is sent, previous auto-save is deleted from the drafts and the sent mail is saved to "Sent Mail" folder. Richard

oops... should have said.... Using TB version 2 beta 1 (20061206) Comment 8 is VERY important when one is trying to establish the definitive email that was issued. Richard

temporarily granting blocking status in case we can find an easy way to fix this, but I'm not sure we can.

It looks like this issue was fixed once before (in 1.5.0.6), see Bug 314009. something may have regressed it.

Scott, I dont think Bug 314009 fixed this issue. That bug refers to drafts not getting deleted when "Send Later" is used. This bug reefers to drafts not getting deleted when "Cancel" is used. I also see that the Bug314009 fix dealt with only "Send Later" issue, and "Cancel" issue was neither realized nor dealt with in that fix. Ideally there should have been a single fix for both bugs as they are but manifestations of a larger issue. We seem to be fixing issues not at root but at all of its manifestations - result would be a very messy code and even more messy modularity indeed. I propose to remove the previous fix and have a new fix at the proper place/level in the code which acts on Compose window being closed rather than the actions that caused the Compose to close.

I'm not sure what the right thing to do is here, but this is what I propose: If the user opens a compose window *and* is not editing a draft *and* does not explicitly save the draft, and then cancels the compose window w/o saving or sending, then we remove the draft. I want to be somewhat conservative about deleting drafts to avoid those pesky dataloss bugs. I'm not proposing to rewrite the way we handle deleting drafts in general - that would be way too scary for 2.0 and it sounds like Ravi was volunteering to do that for the trunk :-)

There is still the worry that people are used to the auto-save behavior, and will be surprised if we start deleting drafts that they thought had been saved. This would be the case where the user writes a draft, it gets autosaved, the user goes away for a bit, then closes the compose window - in that case, they won't get a prompt about the message not having been saved

If the user isn't editing a draft, and has never explicitly saved a draft of the compose window by clicking the save button, and says "don't save" on window close, we'll delete the auto-saved draft. If you have explicitly saved, or are editing a draft, you'll get the latest auto-saved version in your draft folder. Even if the compose window has been auto-saved after the last change, we'll still ask you to explicitly save the draft, and we'll save it again. (I could try to no-op that last save, but that might be surprising...)

Comment on attachment 251290 [details] [diff] [review] proposed fix david, do we need to clear any of these global variables for the cached compose window case? can we use the savedFolderURI attribute on nsIMsgCompose go get the folder instead of manually taking apart the message uri to make it look like a folder uri? Or the savedFolder object I added to nsIMsgCompose in Bug 128996?

I think the answer is yes to all your questions - I'll look into it. I'd like to land this before the beta build, since I'd like it to get some testing...

the global vars are inited in ComposeStartup, which is called in the recycled case, so I think that's OK. The savedFolder object in nsIMsgCompose is [noscript], so I can't use that. The savedFolderURI is only valid if we've actually done a save, which is OK for now, and probably would be good in general. I'll try to rework the patch to do that...

(In reply to comment #21) > the global vars are inited in ComposeStartup, which is called in the recycled > case, so I think that's OK. The savedFolder object in nsIMsgCompose is > [noscript], so I can't use that. The savedFolderURI is only valid if we've > actually done a save, which is OK for now, and probably would be good in > general. I'll try to rework the patch to do that... > Let me know if you want me to land that patch in Bug 128996 so you can access the saved folder object (we can remove the noscript restriction).

this uses gMsgCompose.savedFolderURI, and tweaks some of the calling code to take advantage of it...

I'll remove the dump in the catch, since we hit that code if the draft hasn't been auto-saved...

fixed on trunk and branch

Verified fixed for 1.8.1.2 on Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.2pre) Gecko/20070206 Thunderbird/2.0pre Mnenhy/0.7.5.0 ID:2007020604 Verified fixed for trunk on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a2pre) Gecko/20070206 Thunderbird/3.0a1 ID:2007020603 on Fedora FC 6