auto save should time out much sooner

RESOLVED FIXED in Thunderbird2.0

Status

Thunderbird
Message Compose Window
RESOLVED FIXED
12 years ago
10 years ago

People

(Reporter: asa, Assigned: Bienvenu)

Tracking

({fixed1.8.1})

Thunderbird2.0
x86
All
fixed1.8.1
Bug Flags:
blocking-thunderbird2 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
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

12 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

12 years ago
That'd be sweet.

Updated

12 years ago
Flags: blocking-thunderbird2?
(Assignee)

Comment 3

12 years ago
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.
Attachment #209143 - Flags: superreview?(mscott)

Comment 4

12 years ago
Comment on attachment 209143 [details] [diff] [review]
proposed fix

woot
Attachment #209143 - Flags: superreview?(mscott) → superreview+
(Assignee)

Comment 5

12 years ago
fixed on trunk. I think we'll want to consider this for 1.8.1 branch as well.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
(Assignee)

Updated

12 years ago
Attachment #209143 - Flags: approval1.8.1?

Comment 6

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

Updated

12 years ago
Flags: blocking-thunderbird2? → blocking-thunderbird2+

Updated

12 years ago
Attachment #209143 - Flags: approval1.8.1? → branch-1.8.1?(mscott)
(Assignee)

Updated

12 years ago
Attachment #209143 - Flags: branch-1.8.1?(mscott) → branch-1.8.1+
(Assignee)

Updated

12 years ago
Keywords: fixed1.8.1
(Assignee)

Comment 7

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

Comment 8

12 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

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

Comment 10

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

Comment 11

11 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

11 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

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

(Assignee)

Updated

11 years ago
Duplicate of this bug: 368906

Updated

10 years ago
Blocks: 396094
You need to log in before you can comment on or make changes to this bug.