Open Bug 457136 Opened 14 years ago Updated 8 years ago
drafts should be saving locally often and pushing to the server
As a person composes a message we should be saving as much of their input as we can. Since we probably don't want to hit the server every couple of seconds with new copies of a draft we should save drafts locally at first and then push those local drafts up to the server on a timely basis. This bug requires a number of changes to be done in various areas. Perhaps that makes this a tracker bug? 1) Auto-saving of Drafts to local disk on typing pause 2) Auto-saving of local drafts to remote server if possible 3) Change in Drafts prefs UI 3a) Option for saving drafts locally - specifying local folder (default on) 3b) Option for saving drafts remotely - specifying folder (default on) 4) Better save button in the compose window (current one is overloaded) 5) Discard button in the compose window (since messages should already be saved) 6) Indications in the draft message list view of which drafts have been pushed to the server, if it's possible 7) Super status bar indication of draft work That doesn't look too difficult, now does it...
What are you scared of loosing so much (or happening) that we need to save on every pause? I agree that the current save period of 5 minutes is probably a bit long, and that we need to improve the UI.
The more we can save of a person's input the better. I don't think there exists a reasonable amount of our users work that we should consider throwing away. As often as the local save is possible and network save as often as reasonable for the network. The preference UI should change to be about where things are saved and should they be saved; not how often. The time value of how much I write in one minute to the next can vary wildly. What's important is to save the persons work and to avoid interrupting; on pause seems like a good point for that.
xref bug 304026.
Assignee: bugmil.ebirol → nobody
(I have not read bug 304026) How about a blend...save frequently and quickly locally, but also save to the mail account at frequently dictated by preference. If you have the former, then couldn't the later be done in the background without impacting UI response? I'm thinking in part about people who use their mail store from multiple machines. Having drafts strictly on local presents a problem.
so much for skimming .... yeah, what Bryan said.
suspect this would effectively resolve bugs: bug 304026, bug 147519, bug 368778 and perhaps others . other perspectives welcome, but as this would resolved datalossy issues, I've changed the bug from ENH to major. And asking for wanted-thunderbird+  poor approximate bug query. fixing this bug might resolve one or two in this list: https://bugzilla.mozilla.org/buglist.cgi?type1-0-0=nowordssubstr&short_desc=draft%20&field0-0-0=short_desc&type0-0-1=substring&field0-0-1=keywords&type1-0-1=allwordssubstr&resolution=---&classification=Client%20Software&classification=Components&query_format=advanced&value1-0-0=past%20html%20text%20encryp%20send%20sent%20&short_desc_type=anywordssubstr&type0-0-0=anywordssubstr&value0-0-0=sav%20copy&field1-0-0=short_desc&product=MailNews%20Core&product=Thunderbird&field1-0-1=short_desc
(In reply to comment #7) > *** Bug 304026 has been marked as a duplicate of this bug. *** so, plop has unduped bug 304026 for good reason, and in bug 304026 comment 19 mentions some possible performance concerns that might affect this bug, namely: - ROOT or /home over NFS - slow local disks - local disks using SSD that dislike frequent sync
about slow local disk, few people have ever met this case in real life, but i had: in very rare cases, the local disk (either physical in the box, or network disk) can be, sometimes, slower (in access time AND bandwidth) than the Imap server, and even, some times, less reliable. In such case, if TB automaticly saves draft locally, this can end in perf loss. I am not against autosave. I am just asking for the feature to be OPTIONNAL and CONFIGURABLE through a tick box somewhere. About SSD, in short, there are two kinds of SSD: the expensive ones, that are as much reliable as normal HDDs, and the cheap ones, when you use low cost memory cards with USB adapters or so ... In the later case, frequent disk sync can kill the Flash. In this later case, it's recommended to configure filesystem sync period to at least 5mn, or more. So, either TB will perform normal write of draft, what means the draft won't be sync before 5mn ... => draft is not really saved *or* TB perfoms sync and commit after saving the draft, and if this happens too frequently, daily use of TB could kill the Flash in a few months. So, for those 3 cases, as i just said, users wan't to have a tick box to be able to disable the feature. Except those 3 cases, I am higly favorable to the proposed idea. And, I would add a new point: - the auto-save period should be customisable to lower values. At the moment, the lowest possible poll time is 1mn. I want 10s. Down to 1s is reasonable (with a note, or pop-up showing when people try to set a value below 10s reminding to take care about the filesystem polling frequency - which is 5s for ext3 and ext4, but varies for other FS).
FYI. (In reply to Bryan Clark (Firefox PM) [:clarkbw] from comment #0) > 1) Auto-saving of Drafts to local disk on typing pause This is already possible by addon of "Auto Save Drafts Folders". https://addons.mozilla.org/en-us/thunderbird/addon/auto-save-drafts-folders/ For "long imap server down" case, bug 28211 is already requested. Another answer to this kind of request is "Filter after sending of Message Filter" and iit s already available in trunk nightly. See bug 1119529 for recently fixed outstanding problem in "Filter after sending".
You need to log in before you can comment on or make changes to this bug.