323351 - auto save should time out much sooner

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[Asa Dotzler [:asa]]

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.

Comment 1

[David :Bienvenu]

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.

Comment 2

[Asa Dotzler [:asa]]

That'd be sweet.

Comment 3

[David :Bienvenu]

Attachment: 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 4

[Scott MacGregor]

Comment on attachment 209143 [details] [diff] [review]
proposed fix

woot

Comment 5

[David :Bienvenu]

fixed on trunk. I think we'll want to consider this for 1.8.1 branch as well.

Comment 6

[Scott MacGregor]

Let's let this bake for a bit before we put it on the branch. 

Comment 7

[David :Bienvenu]

*** Bug 307042 has been marked as a duplicate of this bug. ***

Comment 8

[David Fraser]

Testing this on my regular 1.5.0.2 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.

Comment 9

[David :Bienvenu]

*** Bug 349500 has been marked as a duplicate of this bug. ***

Comment 10

[Magnus Melin [:mkmelin]]

*** Bug 349485 has been marked as a duplicate of this bug. ***

Comment 11

[L A Walsh]

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.

Comment 12

[David :Bienvenu]

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

Comment 13

[L A Walsh]

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