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
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/184.108.40.206u SeaMonkey/1.5a Lewis
Component: Message Compose Window → MailNews: Composition
Product: Thunderbird → Core
Version: unspecified → Trunk
*** 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
Last Resolved: 13 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 email@example.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 firstname.lastname@example.org 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
Last Resolved: 13 years ago → 13 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.