Scott asked me to file this into 2.0 bugs. When autosaving, if the connection to the IMAP server is slow, the compose window can "hang" for quite a while. We should time out within a few seconds in this case. It's different than the case where you actually hit the "Save" button because it happens while you're in the middle of typing an email and is very disruptive.
what should happen, imo, is that we shouldn't block the UI when doing the save. We should just take a snapshot of the editor, and then do the save in the background.
That'd be sweet.
Created attachment 209143 [details] [diff] [review] proposed fix with this patch, we don't disable the ui at all during auto save. This should really cut down on the ui glitches. I've also reworked the message changed flag handling because now the user can dirty the message body between the time the auto save starts and it finishes. I've run with this a bit, and it seems ok so far.
Comment on attachment 209143 [details] [diff] [review] proposed fix woot
fixed on trunk. I think we'll want to consider this for 1.8.1 branch as well.
Let's let this bake for a bit before we put it on the branch.
*** Bug 307042 has been marked as a duplicate of this bug. ***
Testing this on my regular 184.108.40.206 install by patching the js file manually Have found this problem noticeable as am using a (fairly slow) IMAP server on another machine to store the Drafts Initial tests show that I can type through the save without any problems. If I encounter any issues with this I will feed back here.
*** Bug 349500 has been marked as a duplicate of this bug. ***
*** Bug 349485 has been marked as a duplicate of this bug. ***
This bug was reported fixed in 2.0. It is not fixed and acts the same as in 1.5 where it was first reported. This is a perfect example of the failure of a claimed bugfix, causing this bug to be marked as "closed", when the original reporters were unable to actually test the fix in the final product until months later. In companies I have worked for, test-fixes were confirmed as fixed by the bug-submitter(s). I use plural -- since some bugs were closed as duplicates of this bug while they _may_ not be duplicates as far as the fix goes. I.e. the fix "fixes" this bug, but not the bugs closed as duplicates (bug# 307042). Also relevent, unless there is a strong reason to do so, duplicates should be dupped to the earliest reported incidence of the bug -- this allows better tracking of first reporting and how long the bug is open before fixing. How can "307042" be closed as a duplicate of this bug when this bug didn't exist until 4 months later. It may be that this bug (auto save should "time out" sooner) was fixed, but 307042 was not fixed -- which says "autosave should save in background". Those are two different symptoms. The fixer tested this bug against a "slow" IMAP server and didn't run into the problem. Apparently the complaint in this bug was that the UI was disabled during save -- and this may very well have been fixed (I don't know, I didn't run into that problem). However the other bug (307042) was where the UI was NOT being disabled, and keys were dropping during the save [on a relatively fast server]. At the very least, I would suggest a "PENDING VERIFICATION" state for a bug where, at least, the submitters of the bug could verify the fix when they get a product they can test (and that doesn't mean one extracted from a nightly development build, but one that is either a "RC" labeled release, though preferably in the final release -- only then can one truly know that the bug is actually fixed in the final product. Case in point.
have you noticed the verified state? I'm sorry this isn't working for you - it's much better for a lot of users, now that we don't disable the UI (which guarantees that keystrokes are lost...)
noticed the resolved/fixed state, but I thought someone in development was able to set the 'verified' state. I'd almost guarantee that if I ran a remote X with the prog on linux, it wouldn't be losing the keypresses (i.e., I'm having it on WinXP2. I vague remember, at the time, thinking it might have been related to an extension. I know it isn't about the slow IMAP server -- the save happens in ~.1 seconds, guestimating. I _usually_ lose only 1 key press, but I've seen as many as three lost, whereas before, I might lose as many as 10+ chars, and minimally 3-4, so it isn't as bad as it was, but it is still happening. @some companies, "verified" could only be set by QA -- who were in a separate department & area from development. I was just going to file it as a new bug, since I don't think it has anything to do with the server speed (I'm the only one on the server, and it is a 2-processor P-III @1GHz each, 1GB main memory, 15K RPM system disk, with the IMAP dir (i.e. Drafts) on a 7.2K RPM IDE; network between client and server is 1GB ethernet).