Closed Bug 307042 Opened 19 years ago Closed 18 years ago

Autosave should save in background

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 323351

People

(Reporter: asvravi, Unassigned)

References

Details

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.
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?
not a sstop ship bug. Feel free to contribute a patch though.
Flags: blocking1.8b5? → blocking1.8b5-
Hi,

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
network.

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.

Philip

*** Bug 313874 has been marked as a duplicate of this bug. ***
*** Bug 317642 has been marked as a duplicate of this bug. ***
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).

FWIW:

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

Lewis
Component: Message Compose Window → MailNews: Composition
Product: Thunderbird → Core
Version: unspecified → Trunk
Assignee: mscott → nobody
*** Bug 319725 has been marked as a duplicate of this bug. ***
*** Bug 319979 has been marked as a duplicate of this bug. ***
in trunk builds, the ui is not disabled during auto-save.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
Does this mean the the proper behaviour will not be available until TB3? Not for TB1.5.x, not for TB2?

*** Bug 332284 has been marked as a duplicate of this bug. ***
This bug was changed to "resolved" & "worksforme" by bienvenu@nventure.com.

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 bienvenu@nventure.com please
reopen it?
what build are you using? A 2.0 nightly or trunk build?
(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?

Lewis
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.
(In reply to comment #15)
> again, what build are you using?
> 
Apologies for the omission. I'm currently using 20060210 on OS/2.

Lewis
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?
-l

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.

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...
it would be more appropriate to mark this as a dup of the bug that contained the fix...bug 323351 - I'll do that.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
fix was in bug 323351

*** This bug has been marked as a duplicate of 323351 ***
Status: REOPENED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → DUPLICATE
This bug was reported as fixed in 2.0.  It is NOT FIXED.
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.