349500 - New text ignored while (auto)saving to Drafts in composer window ("blocking I/O")

Status: RESOLVED DUPLICATE of bug 323351

(Thunderbird :: Message Compose Window, defect)

Description

[Sini Ruohomaa]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.6) Gecko/20060808 Fedora/1.5.0.6-2.fc5 Firefox/1.5.0.6
Build Identifier: Thunderbird 1.5.0.5 (20060808), from Fedora-based distribution

Autosave (maybe also save, I failed to test it) is apparently in practice a "blocking operation" for the composition window's text area. The preferrable result would be that I could keep on typing while the message is being saved (it does not matter if the new text is saved on that particular autosave or not), and the new text would appear on the message at the latest when the autosave is done (in case window refreshing is slow), and not get lost.

Reproducible: Didn't try

Steps to Reproduce:
1. Have your drafts on an account that takes a bit of time to talk to.
2. Type a largeish message to make sure saving takes a moment.
3. Keep typing during autosave.

Actual Results:  
Text typed during autosave is lost.

Expected Results:  
Text typed during autosave a) appears immediately on the composer window or b) appears in full on the composer window when autosave is completed. (a) is preferrable.

Possible workarounds: a) Don't autosave, b) Autosave only on a medium where it is fast enough that you won't manage to type anything during it (?).

Background: I had an unusual delay (of about 5 seconds) in saving to Drafts over IMAP due to our server being on high load and somewhat long message (no attachments though). I have autosave set to every minute.

I was typing away at full speed when autosave started, and was surprised to see that my text from the save-time (5 sec) never appeared. I can identify two probable causes: either the save is done in the same thread as listening for new text, so the listener is not working while the save is in progress. The loss may also have been caused by a pop-up spin "dialog" (informing me autosave is in progress) taking the foucs away from the text area; this kind of interruption also should not happen, especially since the composre window already has a spin field that could take care of informing me in the background (compare e.g. to Emacs autosave).

This was repeated a couple of times, but then the server got fast enough again while I was browsing Bugzilla that I couldn't test it more. Hence "Haven't tried to reproduce it."

I browsed the bug database and found bug 317970
(https://bugzilla.mozilla.org/show_bug.cgi?id=317970), which has a patch, that might be related: there saving hangs on a particular sort of attachment and blocks the entire window, apparently. There were several probable duplicates mentioned in Comment #16 of that bug (https://bugzilla.mozilla.org/show_bug.cgi?id=317970#c16) for variations on the hang. I assume that if saving were done on a separate thread with some protection, the composer window could go on even if the saving froze up, but may be wrong.

Comment 1

[David :Bienvenu]

in 2.0 alpha and trunk builds, auto save doesn't disable the ui...

*** This bug has been marked as a duplicate of 323351 ***