Closed
Bug 16360
Opened 25 years ago
Closed 19 years ago
mail/news compose autosave
Categories
(MailNews Core :: Composition, enhancement, P3)
MailNews Core
Composition
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: BenB, Assigned: Bienvenu)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
Attachments
(3 files, 1 obsolete file)
8.72 KB,
patch
|
mscott
:
superreview+
|
Details | Diff | Splinter Review |
1.04 KB,
patch
|
mscott
:
superreview+
|
Details | Diff | Splinter Review |
2.17 KB,
patch
|
Details | Diff | Splinter Review |
Similar to Bug #16359, but I don't know how much code of editor is used here.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Summary: Auto Save → [Feature] Auto Save
Target Milestone: M15
Comment 2•25 years ago
|
||
So, this is "auto-save" for mail? Where? In a draft message?
Reporter | ||
Comment 3•25 years ago
|
||
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•25 years ago
|
||
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?
Reporter | ||
Comment 5•25 years ago
|
||
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.
Updated•25 years ago
|
Assignee: ducarroz → nobody
Status: ASSIGNED → NEW
Summary: [Feature] Auto Save → [HELP WANTED] Auto Save for mail compose
Whiteboard: [HELP WANTED]
Target Milestone: M15 → M20
Comment 6•25 years ago
|
||
So let's not crash :-)Add to [HELP WANTED] list.
Updated•25 years ago
|
Keywords: helpwanted
Updated•25 years ago
|
Summary: [HELP WANTED] Auto Save for mail compose → Auto Save for mail compose
Whiteboard: [HELP WANTED]
Target Milestone: M20
Comment 8•24 years ago
|
||
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.
Assignee: nobody → rcassin
Reporter | ||
Comment 9•24 years ago
|
||
ccing the previous owner, <nobody@mozilla.org>, in case he is still interested.
Updated•24 years ago
|
Status: NEW → ASSIGNED
Comment 10•24 years ago
|
||
Was that a joke Ben?
Reporter | ||
Comment 11•24 years ago
|
||
A joke? From me???
Comment 12•24 years ago
|
||
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.
Keywords: mozilla0.9
Comment 13•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
Looks like the draft bugs are on the nsbeta1/moz0.8 train so they shouldn't be a problem for much longer.
Comment 17•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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)
Reporter | ||
Comment 20•23 years ago
|
||
> 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•23 years ago
|
||
*** Bug 91517 has been marked as a duplicate of this bug. ***
Comment 22•23 years ago
|
||
> 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•23 years ago
|
||
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 25•22 years ago
|
||
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•22 years ago
|
||
<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•22 years ago
|
||
*** Bug 121308 has been marked as a duplicate of this bug. ***
Comment 28•22 years ago
|
||
*** Bug 156779 has been marked as a duplicate of this bug. ***
Comment 29•22 years ago
|
||
Renominating; it'd be a fine thing to get this for buffy.
Comment 30•22 years ago
|
||
*** Bug 179493 has been marked as a duplicate of this bug. ***
Comment 31•22 years ago
|
||
*** Bug 180376 has been marked as a duplicate of this bug. ***
Comment 32•22 years ago
|
||
*** Bug 188817 has been marked as a duplicate of this bug. ***
Comment 33•21 years ago
|
||
*** Bug 192763 has been marked as a duplicate of this bug. ***
Comment 34•21 years ago
|
||
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•21 years ago
|
||
Mail Triage team: nsbeta1-
Comment 36•21 years ago
|
||
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(); +}
Reporter | ||
Comment 37•21 years ago
|
||
David Grant: Filename?
Comment 38•21 years ago
|
||
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().
Reporter | ||
Comment 39•21 years ago
|
||
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•21 years ago
|
||
*** Bug 196627 has been marked as a duplicate of this bug. ***
Comment 41•21 years ago
|
||
*** Bug 199880 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Summary: mail compose autosave → mail/news compose autosave
Comment 42•21 years ago
|
||
*** Bug 35448 has been marked as a duplicate of this bug. ***
Comment 43•21 years ago
|
||
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•21 years ago
|
||
*** Bug 208081 has been marked as a duplicate of this bug. ***
Comment 45•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
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.
Assignee: rcassin → scott
Status: ASSIGNED → NEW
Comment 48•21 years ago
|
||
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! :-)
Updated•21 years ago
|
Flags: blocking1.6b?
Flags: blocking1.6a?
Updated•21 years ago
|
Flags: blocking1.6b?
Flags: blocking1.6b-
Flags: blocking1.6a?
Updated•21 years ago
|
Flags: blocking1.7a?
Comment 49•20 years ago
|
||
*** Bug 232568 has been marked as a duplicate of this bug. ***
Comment 50•20 years ago
|
||
We're not likely to hold 1.7 alpha for this enhancement.
Flags: blocking1.7a? → blocking1.7a-
Comment 51•20 years ago
|
||
*** Bug 253965 has been marked as a duplicate of this bug. ***
Comment 52•20 years ago
|
||
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
Flags: blocking-aviary1.0?
Updated•20 years ago
|
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Comment 53•20 years ago
|
||
Scott, care to explain the blocking-aviary1.0- ? A simplistic fix seems well within reach...
Comment 54•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
o7ws@yahoo.com: 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.
QA Contact: esther → stephend
Comment 57•20 years ago
|
||
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•20 years ago
|
||
(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...
Updated•20 years ago
|
Flags: blocking1.8a5-
Flags: blocking1.7a-
Flags: blocking1.6b-
Updated•20 years ago
|
Product: MailNews → Core
Comment 59•20 years ago
|
||
*** Bug 271685 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•20 years ago
|
Assignee: mscott → bienvenu
Assignee | ||
Comment 60•19 years ago
|
||
*** Bug 278396 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 61•19 years ago
|
||
patch coming up.
Status: NEW → ASSIGNED
Keywords: helpwanted,
nsbeta1-
Assignee | ||
Comment 62•19 years ago
|
||
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.
Attachment #171290 -
Flags: superreview?(mscott)
Assignee | ||
Comment 63•19 years ago
|
||
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•19 years ago
|
||
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?
Reporter | ||
Comment 65•19 years ago
|
||
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).
Assignee | ||
Comment 66•19 years ago
|
||
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.
Reporter | ||
Comment 67•19 years ago
|
||
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.
Assignee | ||
Comment 68•19 years ago
|
||
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•19 years ago
|
||
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•19 years ago
|
||
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.
Assignee | ||
Comment 71•19 years ago
|
||
the compose window resurfacing is indeed because of the progress window - I'll try disabling the progress window for this case.
Comment 72•19 years ago
|
||
*** Bug 278775 has been marked as a duplicate of this bug. ***
Comment 73•19 years ago
|
||
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
Assignee | ||
Comment 74•19 years ago
|
||
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.
Assignee | ||
Updated•19 years ago
|
Attachment #171290 -
Attachment is obsolete: true
Attachment #171662 -
Flags: superreview?(mscott)
Assignee | ||
Updated•19 years ago
|
Attachment #171290 -
Flags: superreview?(mscott)
Assignee | ||
Comment 75•19 years ago
|
||
default interval to five minutes, turn off auto save by default.
Attachment #171664 -
Flags: superreview?(mscott)
Comment 76•19 years ago
|
||
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.
Attachment #171662 -
Flags: superreview?(mscott) → superreview+
Comment 77•19 years ago
|
||
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...
Attachment #171664 -
Flags: superreview?(mscott) → superreview+
Assignee | ||
Comment 78•19 years ago
|
||
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•19 years ago
|
||
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...
Reporter | ||
Comment 80•19 years ago
|
||
(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.
Assignee | ||
Comment 81•19 years ago
|
||
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•19 years ago
|
||
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);
Assignee | ||
Comment 83•19 years ago
|
||
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•19 years ago
|
||
Seems like David didn't see Neil's comment... Hope somebody will fix it as she/he works on the UI integration.
Assignee | ||
Comment 85•19 years ago
|
||
I've already fixed it for seamonkey...
Comment 86•19 years ago
|
||
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•19 years ago
|
||
(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•19 years ago
|
||
(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•19 years ago
|
||
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 :)
Assignee | ||
Comment 90•19 years ago
|
||
Neil, are you interested in this patch for Seamonkey? You'll also need to add this to the prefs ui...
Comment 91•19 years ago
|
||
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
Assignee | ||
Comment 92•19 years ago
|
||
marking fixed, then.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Updated•19 years ago
|
QA Contact: stdonner → nobody
Comment 93•19 years ago
|
||
*** Bug 302171 has been marked as a duplicate of this bug. ***
Comment 94•18 years ago
|
||
*** Bug 326726 has been marked as a duplicate of this bug. ***
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•