Closed
Bug 323351
Opened 19 years ago
Closed 19 years ago
auto save should time out much sooner
Categories
(Thunderbird :: Message Compose Window, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
Thunderbird2.0
People
(Reporter: asa, Assigned: Bienvenu)
References
Details
(Keywords: fixed1.8.1)
Attachments
(1 file)
4.02 KB,
patch
|
mscott
:
superreview+
Bienvenu
:
approval-branch-1.8.1+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•19 years ago
|
||
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.
Reporter | ||
Comment 2•19 years ago
|
||
That'd be sweet.
Updated•19 years ago
|
Flags: blocking-thunderbird2?
Assignee | ||
Comment 3•19 years ago
|
||
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.
Attachment #209143 -
Flags: superreview?(mscott)
Comment 4•19 years ago
|
||
Comment on attachment 209143 [details] [diff] [review] proposed fix woot
Attachment #209143 -
Flags: superreview?(mscott) → superreview+
Assignee | ||
Comment 5•19 years ago
|
||
fixed on trunk. I think we'll want to consider this for 1.8.1 branch as well.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•19 years ago
|
Attachment #209143 -
Flags: approval1.8.1?
Comment 6•19 years ago
|
||
Let's let this bake for a bit before we put it on the branch.
Updated•19 years ago
|
Flags: blocking-thunderbird2? → blocking-thunderbird2+
Updated•19 years ago
|
Attachment #209143 -
Flags: approval1.8.1? → branch-1.8.1?(mscott)
Assignee | ||
Updated•19 years ago
|
Attachment #209143 -
Flags: branch-1.8.1?(mscott) → branch-1.8.1+
Assignee | ||
Updated•19 years ago
|
Keywords: fixed1.8.1
Assignee | ||
Comment 7•18 years ago
|
||
*** Bug 307042 has been marked as a duplicate of this bug. ***
Comment 8•18 years ago
|
||
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.
Assignee | ||
Comment 9•18 years ago
|
||
*** Bug 349500 has been marked as a duplicate of this bug. ***
Comment 10•18 years ago
|
||
*** Bug 349485 has been marked as a duplicate of this bug. ***
Comment 11•18 years ago
|
||
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.
Assignee | ||
Comment 12•18 years ago
|
||
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•18 years ago
|
||
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).
You need to log in
before you can comment on or make changes to this bug.
Description
•