Autosave should save in background



14 years ago
11 years ago


(Reporter: asvravi, Unassigned)


Bug Flags:
blocking1.8b5 -

Firefox Tracking Flags

(Not tracked)




14 years ago
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)

Auto-save every "x" minutes feature for messages being composed locks
up the composition window and addressing pane whenever it does a save. Auto-save
is expected to be a background save and not lock up compose window. Over a slow
IMAP connection this is really annoying when it tries to save and locks up for
as long as it takes for it to save the message *and* and attachment to server
drafts folder.

Reproducible: Always

Steps to Reproduce:
1. Set drafts folder to be on a slow link, an IMAP server
2. Open a new message compose window and attach a large file
3. Wait for autosave to kick in and try to type something into the compose pane
or addressing pane

Actual Results:  

Typed letter do not show up, the window becomes unresponsive for as long as the
autosave is saving the message

Expected Results:  

It should have saved in the background and allowed message
composition/addressing to continue as normal.

Comment 1

14 years ago
I have also been bitten by this bug, and have sent several mails with 2.5 words
missing.  :-[

Note that this bug only occurs when the drafts mailbox is on an IMAP server, not
when saving drafts to a local folder.
(So, a good workaround for this bug is to use the drafts mailbox on Local Folders.)
The cause of this bug may actually not just be the fact that an IMAP save tends
to take longer than a local save, but an IMAP save shows a dialog box, which
takes away the focus from the compose window - so any keystrokes while saving
are lost.

I'm setting the blocking1.8b5? flag, since I think this really ought to be fixed
before TB 1.5 gets released - this is a potential dataloss bug.
Please forgive me if I'm not supposed to do that - I couldn't find good
documentation on who can set those flags...

 - Michael
Flags: blocking1.8b5?

Comment 2

14 years ago
not a sstop ship bug. Feel free to contribute a patch though. 
Flags: blocking1.8b5? → blocking1.8b5-

Comment 3

14 years ago

the feature, as it is currently designed is completely useless in conjunction
with IMAP servers where you store your drafts on the server. While I understand
that this may not be fixable for 1.5, please consider disabling this option in
said configuration. 

I'm constantly losing words I type whenever TB deceides to save the message. And
this is despite the fact that the IMAP-Server is fast and in the same ethernet

Writing a longer email with the feature enabled always means to be interrupted
while writing, forcing you to go back, fix the incomplete word, rethink what you
were writing and going back to the end to finish the sentence.

For a program centered on usability, this is simply not acceptable. Not having a
autosave-feature is preferable to the current situation as it does not
constantly interrupt your working with the program.

This feature must not be made available if the drafts folder is stored on an
IMAP server.


Comment 4

13 years ago
*** Bug 313874 has been marked as a duplicate of this bug. ***

Comment 5

13 years ago
*** Bug 317642 has been marked as a duplicate of this bug. ***

Comment 6

13 years ago
Could we broaden the product focus for this bug? I have the same gripe about SeaMonkey, and in fact (maybe a new bug?), my CPU can get hogged when autosaving a large draft (or one with an attachment to be mimed).


Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9a1) Gecko/20051201 MultiZilla/ SeaMonkey/1.5a



13 years ago
Component: Message Compose Window → MailNews: Composition
Product: Thunderbird → Core
Version: unspecified → Trunk


13 years ago
Assignee: mscott → nobody

Comment 7

13 years ago
*** Bug 319725 has been marked as a duplicate of this bug. ***

Comment 8

13 years ago
*** Bug 319979 has been marked as a duplicate of this bug. ***

Comment 9

13 years ago
in trunk builds, the ui is not disabled during auto-save.
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME

Comment 10

13 years ago
Does this mean the the proper behaviour will not be available until TB3? Not for TB1.5.x, not for TB2?

Comment 11

13 years ago
*** Bug 332284 has been marked as a duplicate of this bug. ***

Comment 12

13 years ago
This bug was changed to "resolved" & "worksforme" by

Could you please verify what version you fixed this in?

This is a valid bug, it doesn't happen in IMAP because of a "dialog".  I
have no dialog box that pops up, yet I consistently lose keys when 
autosave happens in background.

If this bug hasn't been fixed, would please
reopen it?

Comment 13

13 years ago
what build are you using? A 2.0 nightly or trunk build?

Comment 14

13 years ago
(In reply to comment #9)
> in trunk builds, the ui is not disabled during auto-save.

David, I think the confusion stems from the concept of "disabled." When the autosave occurs (and I see this  - as I've said - in SeaMonkey as well as in TB, on varying platforms), the keyboard buffer stops accepting input (without warning) and then picks up again a second (or more or less) later. Hence, it is entirely possible to be typing the word "the" and then up with "he" or even "e" as a result.

My point here is that while the ui itself may not be disabled (e.g., I may be able to pause from my typing and select something form the menu or toolbar with my mouse, or even press a hotkey, the input buffer definitely hangs while this background saving is going on (and I happen to use mainly POP3 with messages stored locally).

Does this help?


Comment 15

13 years ago
again, what build are you using? Since the UI is not disabled anymore, the editor should not be throwing away keys. The build you referred to /20051201) did not have my change in it. I checked my change into the trunk on 1/23/2006 and onto the 2.0 branch 02/06/2006.

Comment 16

13 years ago
(In reply to comment #15)
> again, what build are you using?
Apologies for the omission. I'm currently using 20060210 on OS/2.


Comment 17

13 years ago
I am seeing this in Thunderbird; version 1.5 (20051201) under XP-SP1. Am I in
the wrong product or something?  I got led to this bug by searching in
Thunderbird bugs.  Someone had closed out another bug (same symptoms) as
a duplicate of this one.  

Specifically, there is no UI disabling -- the original said the compose
window locks up.  My (perhaps incorrect) interpretation of this was
that this was the same problem I am seeing -- it's as though a "type-ahead"
buffer is being zeroed when the save occurs.

Another way to describe symptom.  I am typing: "Now is the time for all good".
The autosave initiates just as I am typing in the word "time".  It takes < 1
second; perhaps something on the order of .1 seconds for the autosave to
happen.  Anyway, the keys I typed during that brief .1 seconds get "dropped"
as though interrupts were disabled and the string I end up seeing in
my Compose window is "Now is the e for all good men".

It occurred to me as I was writing this, that that there can be a "popup" dialog that occurs at saving: "that autosave can't save with a non-standard
identity".  That popup isn't, _necessarily_, happening for the keyloss
to occur, as I'm rarely using that feature.

Does that clarify anything?

Comment 18

13 years ago
law : 1.5 doesn't have the change I mentioned. That won't be officially released until 2.0, so you can't run a build with the change unless you want to try a nightly 2.0 or trunk build. Re the UI not being disabled in your case, it might be getting disabled and enabled really quickly - if the glitch is less than a second, the UI might not even get repainted disabled and then repainted enabled, for all I know...but it's still getting disabled.

Comment 19

13 years ago
Perhaps FIXED would be a better resolution than WORKSFORME, since this only worked after a change was made (that the UI isn't disabled), and thus people are reading it and wondering why its not working for them although it is marked as working (which usually implies that the problem could not be reproduced). If agreed I can change the status...

Comment 20

13 years ago
it would be more appropriate to mark this as a dup of the bug that contained the fix...bug 323351 - I'll do that.
Resolution: WORKSFORME → ---

Comment 21

13 years ago
fix was in bug 323351

*** This bug has been marked as a duplicate of 323351 ***
Last Resolved: 13 years ago13 years ago
Resolution: --- → DUPLICATE

Comment 22

12 years ago
This bug was reported as fixed in 2.0.  It is NOT FIXED.


11 years ago
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.