16360 - mail/news compose autosave

Status: RESOLVED FIXED

(MailNews Core :: Composition, enhancement, P3)

Description

[Ben Bucksch (:BenB)]

Similar to Bug #16359, but I don't know how much code of editor is used here.

Comment 1

[pmock]

changing QA assigned to myself

Comment 2

[Phil Peterson]

So, this is "auto-save" for mail? Where? In a draft message?

Comment 3

[Ben Bucksch (:BenB)]

Phil, are you asking for the place to store the autosave data? I don't know.
Maybe something like emacs #autosave-files#? Local storage seems OK for me.

Comment 4

[Phil Peterson]

Actually, I'm asking for an explanation of this bug report, and I was
speculating that "auto-save to draft" was the feature being requested. What does
auto-save have to do with mail/news?

Comment 5

[Ben Bucksch (:BenB)]

Phil, that I lost emails I composed while surfing and NS crashed. As said in the
description, I filed that bug only, because I don't know if autosave in ender
will automatically be used for mailnews.

Comment 6

[Phil Peterson]

So let's not crash :-)Add to [HELP WANTED] list.

Comment 7

[Phil Peterson]

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

Comment 8

[Ryan Cassin]

I'm reassigning to myself because I'm taking care of the Auto Save in the 
Editor, and it will overlap to the mail-news.

Comment 9

[Ben Bucksch (:BenB)]

ccing the previous owner, <[e-mail]>, in case he is still interested.

Comment 10

[Matthew Tuck [:CodeMachine]]

Was that a joke Ben?

Comment 11

[Ben Bucksch (:BenB)]

A joke? From me???

Comment 12

[Dan Mosedale (:dmosedale, :dmose)]

To reply to Phil's question, I think it should auto-save as a draft every X
minutes (5 or so), and after a successful send, delete the draft.

Nominating this for mozilla0.9, as I think this makes any instability very
significantly less painful.

Comment 13

[Phil Peterson]

dmose, note that our current Drafts functionality does not delete earlier
versions of a draft when a newer version is saved, as 4.x did. See bug 11387
and/or bug 52331. Until that functionality is recreated, "auto save as draft"
could be pretty annoying.

Comment 14

[Dan Mosedale (:dmosedale, :dmose)]

In the medium/long term, I like the idea of saving in the Drafts folder, since
IMAP users will then get location independence by default.  But if those bugs
aren't scheduled to get fixed soon, autosave in the user profile would certainly
still be a lot better than nothing.

Comment 15

[Matthew Tuck [:CodeMachine]]

Those two bugs look like dupes or nearly so.  But anyway, I don't think Mozilla
1.0 should go out without that behaviour being fixed.  I would consider it as
important as this bug.  I'd nominate it as such but I don't know which to
nominate.  =)

Comment 16

[Matthew Tuck [:CodeMachine]]

Looks like the draft bugs are on the nsbeta1/moz0.8 train so they shouldn't be a
problem for much longer. 

Comment 17

[Chris Dolan]

In a variety of difficult to reproduce cases, I've had Mozilla die just after
clicking "send" in the mail composer (or in the middle of spell checking in
Navigator 6.1).  A wonderful aid would be if Mozilla wrote a scratch mail file
to disk before trying to send.  Then if it died, the presence of an "en route"
message could be detected the next time the messenger launched and could be
either sent, or thrown in the drafts folder, or reopened in composer (I'm not
sure which of these three is the right solution).  

Since most crash bugs happen at functional boundaries (like transition from
editing to sending), I think this would catch much of the need for an auto-save
feature.

Comment 18

[Philip Andrew]

1. I agree that the ultimate solution is "Save-as-draft" where
   the previous "auto-save" draft is deleted so there's only
   a single "auto-save" draft at a time; and upon successful
   "Send" (or successful "Save"), and "auto-save" draft is
   deleted.

2. I agree that if the above solution is not feasible in the
   next branch release, that an "auto-save-to-profile" (or to
   a file in /tmp) should be used as a quick-fix interim solution.
   If there is a worry about security (e.g. having an e-mail
   saved in a file is potentially a liability because it is a
   record that someone else might be able to read or otherwise
   exploit), I'd point out that mail messages are saved to files
   all the time when reading (/tmp/nsmail-*, /tmp/nscopy-*), and
   that doesn't seem to bother anyone.

3. I disagree that having the auto-save happen on a functional
   boundary would solve most of the data loss scenarios.  I,
   personally, have never had a crash on "Send"; the crashes
   where I've lost long, unsaved e-mail messages have all been
   situations where I was in the middle of composing a message,
   and I went over to use the browser and something caused
   Mozilla to crash (or hang and be killed).

Comment 19

[Chris Dolan]

I agree with your point #1.  Save to drafts is good, so if your whole computer
dies, you can continue the mail on another machine (if your drafts is a remote
folder) (this is a genuine issue on my crash-prone mac)

regarding point #2, I was not aware that Mozilla saved mail files in /tmp.  Are
they permission 0600?  If not, this is a BAD thing.  Mail must remain private at
all costs.  Frankly I think it's better to lose a mail message than to have it
readable by others.

I *strongly* agree with point #3.  That is how I lose most of my mail.  However,
 I would like to add that mail loss on "Send" is real.  Example: NS 6.1 crashed
in the spell checker on me (had spell-check-on-send pref set -- I switched back
to Moz nightlies in a hurry)

Comment 20

[Ben Bucksch (:BenB)]

> the ultimate solution is "Save-as-draft" where
>    the previous "auto-save" draft is deleted so there's only
>    a single "auto-save" draft at a time; and upon successful
>    "Send" (or successful "Save"), and "auto-save" draft is
>    deleted.

That's exactly how it works now.

> I'd point out that mail messages are saved to files
>    all the time when reading (/tmp/nsmail-*, /tmp/nscopy-*), and
>    that doesn't seem to bother anyone.

People do bother.

> Are they permission 0600?

They should. If not, it's a bug. There is/was one filed about that.

> Save to drafts is good, so if your whole computer
> dies, you can continue the mail on another machine

Draft folder might be on the network (IMAP), and the connection to that server
might fail. Sometimes, it's exactly that situation that makes me want an
autosave. So, saving to the standard Draft folder might not be a good idea, at
liest not in all cases.

Also, you should not overwrite a manually saved draft. I sometimes use it like I
use save in a normal app - as a version that I can get back to, if I dislike
what I wrote.

Comment 21

[Philip Andrew]

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

Comment 22

[Philip Andrew]

> That's exactly how it works now.

Yes, you're right -- "Save" works this way.  Thanks for pointing it out.  But,
of course, there's no "auto-save", and I just wanted to ask that "auto-save"
work the same way as "Save" (and also be integrated with "Save" -- see below).

> Are they permission 0600?

Yes.  I wish that Mozilla at least cleaned these files up when it was done with
them; but I'm not quite sure what it uses them for, so I'm not sure when "done"
is ...
> Also, you should not overwrite a manually saved draft.

Yes, I definitely agree with this.  What I meant is that when you manually
"Save" something, the "auto-save" copy (if any) would be deleted, since it would
just be redundant (until the next "auto-save" interval, anyway).

> Draft folder might be on the network (IMAP).

Good point.  I see four solutions to this:

  1. Always "auto-save" first to a local file (which should
     always be very fast), and then fork a process to copy
     that to the "Drafts" folder.
  2. "Auto-save" to "Drafts", but if there is a failure, auto-save
     to a local file (in /tmp or under $HOME/.mozilla).
  3. Always "auto-save" both to "Drafts" and to a local file
     (one after the other).
  4. Only "auto-save" to a local file.

#1 seems like the best solution, since this way, the "auto-save" doesn't hang up
my Compose session if saving to a slow IMAP server; and also, if the copy fails,
at least there's still a local copy.

Of the others, I'm not sure which I prefer.  #2 would most likely hang up the
COmpose session waiting for a timeout from the IMAP server; #3 could be annoying
because it might make the "auto-save" operation noticeable (esp. if each save to
an IMAP "Drafts" folder takes a "long" -- e.g. noticeable -- time); and #4
offers less flexibility than 1&2, since -- as Chris brought up -- you wouldn't
be able to continue the composition from another machine if your computer died.

Comment 23

[Len Trigg]

Just had mozilla crash near the end of composing a long email. First time it's
ever crashed during compose for me (which is why I hadn't manually saved as
draft at all). Autosave as draft every x min would be a *great* feature. :-)

Comment 24

[scottputterman]

nsbeta1- per ADT triage

Comment 25

[Philip Andrew]

What does that mean?  Is it going to get added?  I lose an e-mail message about
once every week or two, which is annoying to say the least.

Comment 26

[Ian Tommins ('thelem')]

<qa ignore>
It has been reviewed to see if it is a priority for Netscape to fix this for
their next beta version, and it has been decided that it is not a priority
(nsbeta+ means it is a priority, and nsbeta means it is waiting to be reviewed).
This will most likely not be touched by Netscape until the beta has been
released (which I assume is Mozilla 1.0 in this case).

If someone else wants to lend a hand then feel free. In the meantime, just get
into the habit of click that save button (I used to find it often crashed just
as I pressed send, so I got into the habit of clicking save then send).

Comment 27

[xyzzy]

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

Comment 28

[Kathleen :Brade]

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

Comment 29

[Dan Mosedale (:dmosedale, :dmose)]

Renominating; it'd be a fine thing to get this for buffy.

Comment 30

[Matthias Versen [:Matti]]

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

Comment 31

[Boris Zbarsky [:bzbarsky]]

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

Comment 32

[Matthias Versen [:Matti]]

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

Comment 33

[Matthias Versen [:Matti]]

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

Comment 34

[Sim Harbert]

It sounds like this has been around for a long time.  Is there an ETA?  I notice
.9 mentioned and it is now at 1.3.

I think it is a really critical "feature" when it is expected that people are to
be running alpha and beta versions of the software.  I know it isn't the bug
itself, but this is the kind of thing that will keep people like me testing
alpha and beta software.

Comment 35

[Rafael Ebron (:rebron)]

Mail Triage team: nsbeta1-

Comment 36

[David Grant]

Correct me if I'm wrong, but isn't this easy to fix?  Can't we just have a timer
which automatically hits the save button every x minutes?  How about just doing
this simple hack, and creating a prefs.js entry for it (disabled by default),
and then people testing pre-releases can enable it if they want.  I just lost a
message in 1.3b for example.  poo-poo.  Then we (or I should say "you" since I'm
not a developer, but I didn't want to be rude) can make a more robust solution
later, whenever someone decides it's important (at this rate, it will be in
mozilla 4.3a in 2006).

Here's my pseudo-code patch file:

ns/somefile.c:
+if (preference.autosaveMailNews == 1) {
+  someObject.setTimeinMinutes(preference.autosaveMailNewsTime);
+  someObject.startTimer(true);
+}

ns/composeMail.c:
+int someCallBackFcnForTimer(int foobar) {
+   action.save();
+}

Comment 37

[Ben Bucksch (:BenB)]

David Grant: Filename?

Comment 38

[David Grant]

Ben Bucksch: save() doesn't need the filename.  It just saves a draft.  For
people who forget to do CTRL+S right before hitting the send button.  It should
be henceforth called saveDraft().

Comment 39

[Ben Bucksch (:BenB)]

ops, sorry, I was thinking of the HTML Page Composer.
See comment 20 and comment 22 for why File|Save is not a good idea.
Another reason is that subsequent FileSave commands do not delete previous
versions of the same message, and File|Send only deletes the most recent version.

I'd suggest to create a new special folder "autosave" and corresponding internal
function, that works (almost) exactly like Drafts / FileSave.
- We could trigger that without worrying to accidently corrupt the user's Draft
mailbox (in case of errors  - writing mboxes is always dangerous) and
- without overwriting manually saved messages.
- We can also make sure (if that is decided so) that there is always only one
version of a given email saved, unlike in Drafts.
- We can disable the progress meter dialog that comes up for FileSave - it would
make autosave unusable.
- Finally, it allows the user to make a choice if he wants to save the Draft
locally or on an IMAP server. I am not sure what the best default would be:
local as File|Send Later or remote like Drafts. I'd guess remote. However, we
can't save to both local and remote storage unless we explicitly add that (and
add another preference for the local folder).

Comment 40

[Jo Hermans]

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

Comment 41

[Matthias Versen [:Matti]]

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

Comment 42

[Andrew Hagen]

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

Comment 43

[John H. Miller]

It just happened to me :-(  I spent 45 minutes on an email and Windows locked
up.  It wasn't Mozilla's fault, I had too many resources being used and
Micro$oft Windows decided to punish me rather than warn me.

Mozilla is great, Mozilla with Autsave would be even better!

Comment 44

[Jo Hermans]

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

Comment 45

[Clark]

I just lost an email I was working on.  This would be a really great feature to
have.  I have another suggestion on when to save.  Instead of using a timer, 
you could save after a configurable number of key strokes.   

Comment 46

[Todd Buiten]

I hope that you'll all forgive me for my comments here as I realize that I've
paid absolutely nothing for this software and therefore have no valid right to
complain about anything.  It's just that I have this love/hate relationship with
Mozilla because of bugs like this.  In another couple of months this bug will
have been open for four years without a resolution, even after several people
have literally begged for the feature.  Personally I'd much rather have this bug
and a couple of others fixed than to have seen all the work that was done on
other new features because it's stuff like this that gives Mozilla that polished
feel.  If nobody is going to fix the bug then it should just be resolved as
WONTFIX and then we can all go on with our lives.  At least then I can stop
hoping that someday I won't have to manually click the "Save Draft" icon all the
time.

Comment 47

[Scott MacGregor]

My oh my this is a popular bug. Taking. I'd like to develop something like this
for Thunderbird. I'll contribute it back to mozilla. I hope Ryan doesn't mind.

Comment 48

[Jonathan Larmour]

Nearly 3 months after the last comment and still silence?

I've tried to understand what is going on, but I've no experience with mozilla
innards, so I doubt I can fix this myself, but I may be able to give pointers
that should encourage someone to start :-).

The bit that implements the current save-as-draft functionality can be found at
about:
http://lxr.mozilla.org/seamonkey/source/mailnews/compose/resources/content/MsgComposeCommands.js#1666
where msgType==nsIMsgCompDeliverMode.SaveAsDraft (If the line numbers change,
this is in function GenericSendMessage() near the end).

This calls into
http://lxr.mozilla.org/seamonkey/source/mailnews/compose/src/nsMsgCompose.cpp#974
 (nsMsgCompose::SendMsg()) to "send" it to the draft folder

Also relevant is nsMsgCompose::GetBodyModified() to check whether anything
actually needs to be saved (to avoid needless saves if nothing has changed),
although I don't know how to do it for changed headers, but that's less important.

However I don't have any idea about how to set a callback timer so that this
happens, nor any of the UI aspects (or at least something in prefs.js for now)

Please someone help me stop losing my mails! :-)

Comment 49

[Pratik]

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

Comment 50

[Asa Dotzler [:asa]]

We're not likely to hold 1.7 alpha for this enhancement. 

Comment 51

[Scott MacGregor]

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

Comment 52

[Daniel Mota Leite]

someone here in the work have lost a VERY important mail, very hard to recover
due time limit (most places needed to talk again for the information are already
closed) and so thunberbird looked a very bad email client...

the crash was not from thunderbird, it was windows XP crash, so we cant even say
"lets make thunderbird/mozilla crash anymore"


i suggest a autosave to draft on every X characters wrote, the default about 80
(one line lost isnt a big deal, all the email is...)

i suggest blocking aviary and the dataloss keyword (someone with enough power
add it please), as losing a simple email might not be important, but using
thunderbird in a important job this is critical

again, several people here in my job were shocked that thunderbird didnt had any
way of recovering a email lost while composing and only manage to convince the
guy that lost the email to not switch because i was writing this here, so he
will wait to see if this is implemented (but he will be using MS word to write
the emails and then copy past to thunderbird!! trusting more in MS office than
in mozilla is a BAD thing...)

i wouldnt even wait for bug 11387, its better to have several mesg in the draft
than to lost the email

Comment 53

[Eyal Rozenberg]

Scott, care to explain the blocking-aviary1.0- ? A simplistic fix seems well
within reach...

Comment 54

[JoSH Lehan]

Agreed.  It's hard to believe Mozilla doesn't have autosave for email, when they
are trying to give the impression that Mozilla is more reliable/trustworthy/etc.
than Outlook/MSIE.  An autosave feature is fairly trivial, and would save a LOT
of people a LOT of frustration.

There's already a Drafts folder, created by default, as part of the standard
folders.  This would be an ideal place to autosave.

Three considerations:

1) The autosave time interval should be configurable.  5 minutes is probably a
good default choice.

2) The idea of  autosaves after a certain number of keystrokes have been entered
is also a good one.

3) Autosave I/O should be done as a background thread, so that slow writes to
disk/network/IMAP/etc. do not freeze up the editor.  When a time interval or
keystroke interval is reached, a notification could be sent to the autosave
thread, and the main thread could continue unhindered.

Comment 55

[o7ws]

I need to make a plea to elevate this bugfix to highest priority.

There are enough users posted here who are experimenting with or fully dependent
on Thunderbird or Mozilla Mail/News component as their office email client.  In
our office, we've had more crashes (lost email in mid-composition) since we
migrated from Outlook to Mozilla.  I'm not here to blame Mozilla - it may be
coincidence, but I do have to defend this migration.  

I think I am in a similar cirumstance as are many other IT people, who need to
justify why to use a "new" email client.   And cost, and my personal preference
to support open source projects, will never win the argument when you are faced
with the "risk"  of losing valuable work.

Think of how big a difference it makes for word processing programs; whether is
the word-processor or the operating system or something else - users don't
really mind Word crashes as long as they have auto-saved copy.  I think this
would make a huge difference in making new users comfortable with a different
email client and remove the reluctancy of IT managers hesistant to migrate.  And
it would be another distinguishing feature of Mozilla/Thunderbird.  

Comment 56

[timeless]

[e-mail]: if you happen to have resources available, then i'd suggest you
direct a real letter to mozilla foundation. beyond that, as an it person, do you
have some way to collect talkback incident ids from your installed userbase?
perhaps we need some way for talkback to indicate that it's user is part of a
domain so that we can try to catch things faster.

--
the fact is that we don't have many resources or coders who can work on things.
your best bet is to contract w/ mf, mozdevgroup or beonex if you're in a hurry.
or perhaps even reconsider using mozmail for mail compositions. unfortunately i
learned (*mostly, sometimes i'm foolish, and then i regret it and kick myself
for not having completely learned my lesson) a long time ago to write my essays
in notepad and copy them into the browser, mailcomposer or composer (for
spellchecking) when i'm done.

as for blaming mozilla, it's almost certainly our fault, but without the
talkback ids for the crashes, or people to skim through them, it's likely
nothinig will happen for a while.

Comment 57

[David Grant]

c'mon, it's free software, stop your bitching.  Go and use Micro$soft LookOut if
you want and use Word to compose emails.  Or press CTRL-S every after every
sentence.

Comment 58

[Tom Metro]

(In reply to comment #18)
> 2. I agree that if the above solution is not feasible in the
>    next branch release, that an "auto-save-to-profile" (or to
>    a file in /tmp) should be used as a quick-fix interim solution.
[...]
>    I'd point out that mail messages are saved to files
>    all the time when reading (/tmp/nsmail-*, /tmp/nscopy-*)...

When my Windows machine crashed at the point of sending out an email from
Thunderbird (the crash wasn't caused by Thunderbird), I was pleasantly surprised
to find that the message was saved in a nsmail-1.eml file in my temporary files
directory. (I had remembered reading this ancient 2001 comment and decided to
take a look.)

Going back and experimenting, it appears this file exists only momentarily -
during the SMTP transaaction. Also, I don't see any evidence that temporary
files are used when reading, at least not in current Thunderbird releases. So
the quoted comment wasn't quite right.

Still, this could be handy to know for those who happen to experience a crash at
the right moment.

From a security perspective, I would think these temporary files should end up
getting handled the same way as whatever happened to the temporary files that
existed when reading messages. I'm guessing the code was restructured to
eliminate them. But this is a matter for another bug report...

Comment 59

[Mike Cowperthwaite]

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

Comment 60

[David :Bienvenu]

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

Comment 61

[David :Bienvenu]

patch coming up.

Comment 62

[David :Bienvenu]

Attachment: first cut for hidden pref

This patch adds a hidden pref, "mail.compose.autosaveinterval", which specifies
an auto save interval, in minutes.

If you have an imap drafts folder, this still saves to your online drafts
folder - I know Seth suggested saving to the local drafts folder in that case,
but I think that's extra credit. If you're in offline mode, we will save it
offline correctly. The only issue is if you're online but not connected to a
network...

I need to add some prefs UI for this.

Comment 63

[David :Bienvenu]

one problem with this patch is that when an autosave fires, the compose window
comes forward. I'm not sure if its when autosave starts or finishes, but it's
annoying...I'm not sure what's causing this.

Comment 64

[Calum Mackay]

Wonderful :)  thanks for this.

Re where to save the draft: given that each account already has an explicitly
set drafts destination, shouldn't that be honoured for auto-save, also?

Comment 65

[Ben Bucksch (:BenB)]

bienvenu, thanks for taking this.

But please see comment 20, comment 22 and comment 39. (I'm not sure, if I still
completely agree with my comment 39, though.)

> when an autosave fires, the compose window comes forward.
> I'm not sure what's causing this.

It might be the progress meter (in its own window) mentioned in comment 39, at
least in the case of IMAP.

Also, if you really do want to use SaveAsDraft (and consequently overwrite
manually saved drafts), you probably want to check the dirty flag of the editor
(i.e. if there were any changes) before invoking it (SaveAsDraft doesn't seem to
do that, because it's typically manually invoked, where it would be
inappropriate to ignore the user's wish).

Comment 66

[David :Bienvenu]

thx, in my tree, I am already checking the editor documentModified flag. 

My overriding concern is keeping this simple, so we can this important feature
checked in. For imap users who want autosave but are often disconnected but
still in "online" mode, I'd suggest using a local drafts folder. If we can get
necko to tell us if we're really connected to the internet or not, then this
problem will take care of itself. Also, if we can throw up an option to go
offline when this happens, that would help too.  I think the simplicity of using
the same drafts folder as the manual save as draft command will make it a lot
easier for the user to find his autosaved drafts, as well as keep the code that
cleans up the drafts folder simple.

Comment 67

[Ben Bucksch (:BenB)]

I see and understand your concern to implement this without too much effort.
Something is probably better than nothing, esp. when the user has to explicitly
enable a hidden pref. I just concerned about cases where I conciously save a
longer mail as draft before I make changes I am not sure about. I think MS Word
and co also autosave to a different location for this reason.

I looked a bit into adding a new special folder type for autosave (so that you
can define a different folder to save to), but the design of this code ....
doesn't make it easy:
XUL sends 
GenericSendMessage(nsIMsgCompDeliverMode.SaveAsDraft);
to C++ land
<http://lxr.mozilla.org/seamonkey/source/mailnews/compose/resources/content/MsgComposeCommands.js#1858>

That then uses this flag (defined in IDL) to find the special folder
<http://lxr.mozilla.org/seamonkey/source/mailnews/compose/src/nsMsgCompUtils.cpp#1994>
or
<http://lxr.mozilla.org/seamonkey/source/mailnews/compose/src/nsMsgCopy.cpp#219>
or ?

Worse, unfortuantely, that same flag is used in a lot of places
(see the cpp file quotes in
<http://lxr.mozilla.org/seamonkey/search?string=SaveAsDraft>)
where I think it determines the format of the message.

So, this doesn't look very feasible currently, given how the code is designed. :-(

> If we can get necko to tell us if we're really connected to the internet

Even if you're connected to the Internet, the connection to the mail server may
be fragile or Mailnews' IMAP connection is stuck.

Comment 68

[David :Bienvenu]

I am going to add prefs UI to turn this on. But, it is up to the user. There's
definitely a trade-off here, but we do have undo, etc, so the scenario where you
make changes you're not sure about will only be a problem if we crash after
that, which is another order of magnitude less likely...

Re stuck imap connections, we're about to have timeouts in necko, which should
ameliorate that situation...

Comment 69

[Tom Metro]

Ben Bucksch in Comment #67 writes:
> [I'm] just concerned about cases where I conciously save a
> longer mail as draft before I make changes I am not sure about.

I'll second the sentiment that while a partial solution here is better than
nothing, the ideal approach would be to isolate the storage of auto saved drafts
and user saved drafts. I don't see a problem with them being in the same folder,
but they should be logically separate "files" (messages).

As Ben points out, Word and most editors use an altered file name to keep the
automatically saved copy independent of the user saved copy.


> I looked a bit into adding a new special folder type for 
> autosave...but the design of this code doesn't make it easy...

I haven't looked at the code, so I don't know how SaveAsDraft correlates the
message being saved with a prior copy that might already exist in the drafts
folder. Perhaps using the message ID?

Whatever the mechanism, can you intervene prior to calling SaveAsDraft so the
message gets stored independently? (Say temporarily altering the message ID, if
that was the mechanism used.)

Even if possible, I suppose this would also mean that the code that cleans up
drafts upon a successful send would need to be altered to also clean up any auto
saved drafts.

While I don't think a dedicated folder is necessary, a nice future enhancement
would be visually distinguishing auto saved drafts from manually saved drafts
when viewing the drafts folder. 

If auto saved drafts were flagged in some way, it would also make it possible to
for code to execute on startup that alerted the user to any lingering auto saved
drafts, perhaps opening them up into a composer window. If this was done, the
actual storage location (be it the drafts folder or some other place hidden from
the user) would be irrelevant.


Ben Bucksch in Comment #65 writes:
> But please see comment 20, comment 22 ...

The discussion in those comments regarding where the auto saved draft gets saved
seems to favor a solution to guard against an unlikely occurrence (computer
crashes beyond repair) over a far more likely fault (loss of network connectivity).

I think if you consider both performance and reliability, while still keeping
things simple (and thus not implementing options 1, 2, or 3 in comment #22),
saving to a local file is the way to go.

The only practical down side is that if it isn't the users default location,
finding the auto saved draft could be a problem, but my suggestion above
(automatically re-opening any auto saved drafts upon restart) could mitigate that.

However...

Ben Bucksch in Comment #39 writes:
> I'd suggest to create a new special folder "autosave" and 
> corresponding internal function...
> - We could trigger that without worrying to accidently corrupt the 
> user's Draft mailbox (in case of errors  - writing mboxes is always 
> dangerous)...

Not only dangerous, but quite inefficient. Having not looked at the code, I
won't be presumptuous. It may be sufficiently optimized to that performance
wouldn't be an issue, but normally modifying a message in the midst of a
Berkeley mailbox file requires rewriting the entire file, which could be rather
slow for users with a sizable Drafts folders. Not something you'd necessarily
want to be doing every 30 to 60 seconds.

Considering that, it may actually end up being more efficient to save it to an
IMAP hosted Drafts folder, where the chances are greater that it'll use a more
efficient mailbox format. But that obviously isn't a general solution.

It almost feels like a solution that would address both the problem of
conflicting with user's manually saved drafts and performance would be to use
local, individual, per-message, temporary files. Though isn't that what Netscape
originally implemented? (See early comments in this report.) Maybe
re-implementing Netscape style temporary files, with tweaks to improve the
security of them, would be the way to go.

Comment 70

[Met - Martin Hassman]

My experience from Pegasus mail (which saved my mails every time - I am happy
for it) is, that during the work user do not know about auto-saving messages.
They are saved as some tmp files not viewable in Pegasus folders.

But when the computer (or program) crashes and you start it again, the user is
alerted like "There are 2 recovered mails, do you want to open them?" "Or ..you
can find 3 recovered mails from the last session in the folder XY" etc.

I think both is important:
a) do not confuse user with autosaved messages and
b) inform him about existence of recovered mails and where to find them.

If you still want to auto-save it in draft folder (which can possibly corrupt 
draft folder completely if the computer crashes during autosaving), you can mark
them as "normally unvisible" (some X-attribut?) and unhide then only during
recovering.

Comment 71

[David :Bienvenu]

the compose window resurfacing is indeed because of the progress window - I'll
try disabling the progress window for this case.

Comment 72

[Mike Cowperthwaite]

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

Comment 73

[L A Walsh]

I'm not sure where this is leaning, but wanted to chime in w/my opinion
(late though it may be).

In regard to saving it on sending or 
saving on an unexpected exit.  This isn't the greatest thing to do as
the 'corruption' that causes the unexpected exit might have corrupted
the save mechanism.  

Only periodic saves to the "Drafts" folder seem logical, predictable and least 
surprise -- especially for ex-Outlook users.  Auto-saved drafts
would be deleted on successful send.  

I can't say that saving a draft in "Drafts" beyond the time it is "Sent"
seems logical.  If one has sent the draft, it is no longer a draft, but is
"Sent" email.

linda

Comment 74

[David :Bienvenu]

Attachment: proposed fix

this adds a composition pref ui for turning on auto save. It also turns off the
progress window for auto save so that we won't have it pop up and make the
compose window grab focus.

I've got corresponding changes to mailnews.js for giving these prefs default
values, which I'll also attach.

Comment 75

[David :Bienvenu]

Attachment: mailnews.js changes

default interval to five minutes, turn off auto save by default.

Comment 76

[Scott MacGregor]

Comment on attachment 171662 [details] [diff] [review]
proposed fix

looks good David. I think your option plus the inline spell check option in the
compose panel of the options  dialog is probably going to force us to make the
dialog taller by default. But i can do that when the spell checking changes
land.

Comment 77

[Scott MacGregor]

Comment on attachment 171664 [details] [diff] [review]
mailnews.js changes

your tcptimeout is still in this patch I thought that landed already but maybe
I'm mistaken. Doesn't matter either way...

Comment 78

[David :Bienvenu]

oh, thx, no, the tcp timeout hasn't landed because I'm waiting for Darin's patch
to get sr'ed and landed. Darin's waiting for Boris for an sr - don't know if
he'd accept your sr :-) you could ask him. Adding the default tcptimeout pref is
relatively harmless.

Comment 79

[David Grant]

Is this going to go into Thunderbird? Anyone feel like making a Thunderbird
extension? Maybe I'll try, although I don't have the first clue how to do it...

Comment 80

[Ben Bucksch (:BenB)]

(In reply to comment #79)
> Is this going to go into Thunderbird?

Yes, the patch is against Thunderbird.
David, it would be nice to enable that in Mailnews, too. (Currently Thunderbird
only, unless I missed a major source reorg.) Or I could do it. Probably fairly
straightforward.

Comment 81

[David :Bienvenu]

yes, this patch is for thunderbird. It should be very easy to make it work in
seamonkey. The MsgComposeCommands.js diffs should apply relatively cleanly to
seamonkey, so the only work is adding the prefs ui, which should be a fairly
simple cut and paste.

Comment 82

[[e-mail]]

Comment on attachment 171662 [details] [diff] [review]
proposed fix

To whomever ports this to the Suite:
>+gAutoSaveTimeout = setTimeout("AutoSave()", gAutoSaveInterval);
The two lines like this should of course say
gAutoSaveTimeout = setTimeout(AutoSave, gAutoSaveInterval);

Comment 83

[David :Bienvenu]

Attachment: seamonkey MsgComposeCommands.js patch

this is the exact same code, but it applies to Seamonkey FE...I'll check this
in. That leaves only the UI for the compose prefs

Comment 84

[Giacomo Magnini]

Seems like David didn't see Neil's comment... Hope somebody will fix it as
she/he works on the UI integration.

Comment 85

[David :Bienvenu]

I've already fixed it for seamonkey...

Comment 86

[Eugene Savitsky]

This way fixing this bug is not right.

I use IMAP (so, the draft folder is on the server) and when it saves the draft
it takes about 3-5 seconds -> when I am unable to write the message. Maybe it
should be more intelligent way? Say it saves the draft locally and then puts on
the server in other process (or whatever), so the writing is uninterruptible?

Comment 87

[Robert Kaiser]

(In reply to comment #86)
> This way fixing this bug is not right.

Please be more poilte to the developers. It actually _is_ right for most cases.
If you would say "This approach is problematic for IMAP, where saving to the
on-server drafts folder may take quite long", then developers working on this
are more likely to listen to you.

Comment 88

[L A Walsh]

(In reply to comment #86)
> I use IMAP (so, the draft folder is on the server) and when it saves the 
draft
> it takes about 3-5 seconds -> when I am unable to write the message. Maybe it
> should be more intelligent way? Say it saves the draft locally and then puts 
on
> the server in other process (or whatever), so the writing is uninterruptible?
--------
   I use imap as well, and I would prefer my drafts to be saved in my
default account.  Perhaps if choice is wanted (not adverse to choice, in any
case! :-)), Draft auto-saving, could be selectable to a selectable folder --
just like "Drafts" and "Sent" now?  However, I might note -- that saving drafts
in my imap folder takes <1 second and doesn't appear to interrupt my typing --
i.e. even though characters may not be echoed during the save, they are still
input while typing (an inconvenience, I admit).  It would be more ideal if
the auto-save occured in "background" like saves in "MS Word", "vi" 
or "Outlook".  Even Outlook was able to save to an imap store in the background
while a separate thread ran the GUI and allowed the user to continue editing.

There is no annoying "pop-up" when documents are autosaved -- funny -- even
though I have Thunderbird set to "not ask" on saving to folders, it still
feels compelled to throw up a "pop-up".  Might I suggest that this is generally
unnecessary and would definitely be 'unwanted' during "autosaves"?

Also, unlike the current setup -- I really would prefer 1 Draft/message I
am editing.  I definitely *don't* like the feature of creating a new message
everytime I press "control-s", when all I want to do is "checkpoint" my
draft.  After I have sent the draft, I would like checkpointed drafts to be
automatically deleted.  If I want to explicitly save a copy, there could be
a "Save-In" option under "File" to save to an explicit folder.  Even if saved
in the "Draft" folder, an explicit save would not be auto-deleted on sending --
 as it could be marked as a "non-transient Draft".

What is needed is the ability to autosave "transient drafts" that are deleted
after sending (and recorded in the Sent mail folder, if so configured).

-linda

Comment 89

[Patrick]

What's the current status on this? This is a CORE bug, but if i'm not mistaken
it's fixed for the Thunderbird trunk but not ported to Seamonkey? Or it IS fixed
for Seamonkey, per comment 85, but not marked FIXED yet?

Maybe someone can add the current status to the whiteboard?
Thank you :)

Comment 90

[David :Bienvenu]

Neil, are you interested in this patch for Seamonkey? You'll also need to add
this to the prefs ui...

Comment 91

[[e-mail]]

If you'd bothered to look at the dependency tree you'd have seen that it's
already fixed for the Suite. The patch even had sr=bienvenu too :-P

Comment 92

[David :Bienvenu]

marking fixed, then.

Comment 93

[Mike Cowperthwaite]

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

Comment 94

[zug_treno]

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