324110 - Autosave causes mail composer window to hang

Status: RESOLVED DUPLICATE of bug 319818

(Thunderbird :: Message Compose Window, defect)

Description

[Colin Smith]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

The bug is present in Thunderbird version 1.5 and the latest build 1.6a1: (version 1.6a1 (20060119))

When replying to an HTML mail which contains embedded images, or, editing a saved draft of a mail containing images the autosave function within thunderbird causes the mail composer window to "hang".

It isn't completely dead but typing and editing is unavailable. The window reports "attaching" at the bottom and when closed it says it's currently attempting to send a mail and asks if it should cancel. When closed, only the previous version of the draft message is available.

I've tried this with a new profile as well as both versions of thunderbird.

Reproducible: Always

Steps to Reproduce:
1. New profile
2. edit preferences ->composition ->general, turn on autosave every 5 mins. (this should be enabled by default BTW)
2. Create a new mail
3. format page colours and backgrounds.
4. Set the page background to include a tiled image
5. write some text
5. insert additional images embedded in the text
6. Save the mail as a draft and close the window.
7. Open the saved draft message
8. begin typing and wait for autosave
Actual Results:  
The composer window becomes unresponsive and further editing is impossible, the only option is to close the window and go back to the previous version of the saved draft message.

Expected Results:  
I'd have expected the autosave to complete in a second or two and return control to the user so that I can continue editing the message.

This is a bug in the the Linux version of Thunderbird 1.5, 1.6a1 running on a recently updated Fedora Core 4. No idea if it's in the Windows version.

Comment 1

[Adam Guthrie]

Note that bug 317970 is marked as FIXED, but the patch didn't make it into the branch that 1.5 was built from.

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

Comment 2

[Andrew Schultz]

> the patch didn't make it into the branch that 1.5 was built from.

Neither did the patch that caused bug 317970.  Also, if the reporter is seeing the bug in a trunk build 20060119, then it can't be 317970

Comment 3

[Andrew Schultz]

[actually sounds more like the compose window just gets hosed, rather than a hang]

Colin: can you narrow down the list of steps to reproduce to include only those necessary to reproduce the bug?

Comment 4

[Colin Smith]

Sure.

1: Turn auto save on.
2: Write a new mail.
3: Format -> page colour/bacground and add a background image(PNG) for a tiled background.
4: Insert a second image, embedded in the text.
5: Close the compose window and reopen the draft mail from the drafts folder.
6: Wait for autosave.

The composer window greys out the To: and Reply-To: lines and reports "attaching" in the status bar. It's possible to select text in the text area but not to edit it. Interestingly it requires the background image to be a PNG file rather than GIF to activate the bug.

I've just tried it with gif files as embedded image and background: fine. Png file as embedded image and gif as background: fine. But the compose window with embedded gif and a png file as the background has hung.
 

Comment 5

[Frank Wein [:mcsmurf]]

So it also hangs when manually saving this mail (as draft)?

Comment 6

[Colin Smith]

Just tested. Yes, when opened from the draft folder and then choosing manually to save the email it also fails in exactly the same way as with autosave under the same conditions.

Comment 7

[Paul Macey]

This occurs when I have pasted images directly into the compose Window; if I close the compose window and open the saved message (under "Drafts" folder), the saved message is fine. However, when I go to paste a new image after the next autosave, the image does not paste properly and sometimes hangs the window. 

Comment 8

[Jerry]

This bug started around 1.5 and continues in 2 alpha 1 2006426. What appears to happen is that you are allowed one <cntrl>-S or one auto-save and that works. UNLESS you exit or shutn down the message and then re-open it, the next "save" of either type will hang and the message just loops. A line says "attaching" but it just keeps running. 

The problem appears to be related to copying/saving .jpgs or .doc files in t-bird since the two happen in the ame message. I have not tried to separate these problems. 

I use T-bird to write a large weekly newsletter with a good number of jpgs, gifs and a lot of copying and pasting and this drives me nuts and can cost a lot of time. 

Comment 9

[Lucius Chiaraviglio]

Under Thunderbird 1.5.0.2 in Windows XP SP2, I get a much less severe (but still
annoying) problem when composing plain text messages (I have not yet tried all
of the above instructions for message rich formatting and embedded/background
images).  It might be related, so I am including it in here.

When auto-save occurs, the message composition Window temporarily stops accepting
keyboard input; it does not store typed characters for later insertion, either.
This lasts for about 2 seconds, and then it works normally until the next
auto-save.  The only data I lose are the characters typed during the auto-save.

Perhaps 2 bugs are at work against the original reporter:  the annoyance one
that makes the Compose window quit working until auto-save is done, and then
the critical one that makes auto-save (or save to Drafts) never finish with
certain image combinations?

Comment 10

[mxxxm]

Attachment: Thunderbird hangs after second save

I think this is the result of the bug.

Comment 11

[mxxxm]

Confirmation of this bug (similar is: 319818   and maybe: 335218 , 325340

I confirm this bug. But the hang occurs becouse of embedded image(s) in the mail saved, then reopened from Drafts to edit and saved for the second time (doesn't matter if saved manualy or AutoSave). It also happens when reopened to edit, saved for the first time (still fine) an then sent (message is sent to recipient but when copied to the Sent folder Thunderbird hangs).

It doesn't matter what kind of image file type we use (bmp jpg gif png = All hangs).

It happens on Linux and Windows XP (as I wrote in comment in bug report 319818).

With regards mxxxm.

Comment 12

[mxxxm]

Note:

I just want to add note to my previous bug comment (mxxxm). I forgot to add very important two words. So the right meaning is:

"I confirm this bug. But I THINK the hang occurs becouse of embedded image(s)..."

I am not a programmer or a developer of Thunderbird, so I have no responsibility to talk like: "I am 100% sure the bug is becouse of...".

I am only user of the software, but I am sure in saying: "I confirm, that the bug happens the way this report says and ALSO the way I wrote in previous comment (which shortly describes the BUG No. 319818 - that I confirm too)."

So I apologize for the missing "two words".

mxxxm

Comment 13

[John Murphy]

Maybe this will help.
When there is a signature (with an image), the first couple of times it is either saved as a draft or autosaves as a draft everything appears to be OK - and if you double click on the image it shows the "right" location of the image.  However, after a few more saves (dunno how many) the window will hang - then if you double click on the image it will show somehting like:
mailbox:///home/john/.thunderbird/7jsyaez5.default/Mail/mail.emektechnology.com/Drafts?number=16102495&part=1.2&filename=degem001.jpg
where it should just say something like:
file:///home/john/SigsforTbird/degem001.jpg
and in fact if you reset it to this - everything goes back to behaving itself.

Comment 14

[Sebastian Lisken]

I can confirm this bug using Thunderbird 1.5.0.4 and an IMAP account (where drafts are saved into a folder on that account). Perhaps the IMAP bit is important for this to become annoying. It is especially bad if you attach a large file before finishing your message. But this is not related to the type of message (plain v HTML), I think, only the size of the message.

While autosave is at work for an IMAP account:
- the subject field and the header area on top are disabled
- positioning the cursor in the message (body) textarea works (but the text cursor may be invisible)
- typing into the message area does not work
- deleting single characters with backspace does not work
- deleting a whole word with Ctrl+Backspace works. How weird is that?

As a kind of proof, here is the result of typing a plaintext message with an IMAP account. (The connection is a DSL connection to a large national ISP in my country, Germany.) This was the complete message. You can probably see how I just went typing along the top row of the keyboard, from 1 all the way up to 0, then back to 1, and so forth. I was not typing very fast, using just my right index finger (you try hitting every single key exactly right!).

Hallo,
12345678909876543212345678954321

You can see that the sequence "09876" was missing - five keystrokes.

Comment 15

[Charles Faulk]

Charles Faulk - TB ver = 1.5.0.4.  System = Win XP SP2, 2.6 GHz, 512 MB RAM, Plenty of disc space

I believe that the following might help to confirm this bug.  Below are always reproducable.  This mainly deals with saving and sending files with inserted images in Thunderbird composer but it also works with received files to be forwarded. Original images also may not load to a once 'save'd' file from which they were deleted.  Note that OS = Win XP SP2.

The first ‘save’ in a session works OK but the second ‘save’ (with or without making any changes to the file) results in the pop-up window "Saving Messages" displayed with Status: = "Attaching" and the Progress bar just continuing to roll on and on.  

This would also happen with a ‘send’ if the ‘send’ followed the first ‘save’ in a session.
	
With 1 image insert, repeated ‘save’s’ were no problem.  With 2 or more image inserts the second ‘save’ run lasted over 5 minutes, when I terminated it.  This problem does not occur with text-only files or with attached (vs. inserted) files with or without images.

The workaround is to (1) save and exit the document after any changes and (2) reload the document to continue working or send the document, which is cumbersome.

I also uninstalled TB ver 1.5.0.4 and installed TB ver 1.0 (20041206) and found that the problem went away under ver 1.0 and came back with ver 1.5.0.4.  So, it seems to me that something changed from 1.0 to the latest version of TB.

I have also reviewed bug #319818 (which has a severity of 'normal') and I agree with [e-mail] that both bugs are 

probably the result of the same core problem bug(s) affecting at least the composition, sending and receiving of message files with image insertions.

Respectfully submitted,
Charles Faulk MD

Comment 16

[João Pedro Afonso]

(In reply to comment #15)
> I have also reviewed bug #319818 (which has a severity of 'normal') 

  At that time, I had a more serious bug to report, so this one I classified only as "normal"... it was perhaps an erroneous decision, but I trusted the assignee to correct the classification. This is only to say to the programmers or bug hunters, do not trust the severity classification of some reporters like myself.

> and I agree with [e-mail] that both bugs are 
> probably the result of the same core problem bug(s) affecting at least the
> composition, sending and receiving of message files with image insertions.

  I agree with both. The two bugs appears to be due to the same mechanism (actually, if I center on the original report, it appears more or less, to be the same bug). What bugs me is what changes from the first save to the second, for images already presented in the message to edit. Why fresh images can be saved any number of times, but not the ones readed from the saved message. What is different?

  Forgive me the off-topic, but I had lost my hope of seeing bug #319818 treated or considered.

  Cheers,

Comment 17

[Charles Faulk]

Assuming that 319818 and 324110 (under discussion) are due to the same or similar bug(s) then the following applies to both.

Worikng with bugs 319818 and 324110 [e-mail] shows that this bug or bug(s) first showed itself to the public after TB release ver 1.5 (20051201).   Looking at the Bugs FIxed for each release that are similar to the bug(s) above, one finds that the only bug listed as fixed or changed in this area is 301649 - the "spin indefinitely" part is especially relevant.

"TB ver 1.5  Bug 301649 'Fixed 8/30/05'
-------------------------------------------------------
301649: Invalid local image filenames cause forwarded-inline messages to spin indefinitely on send.

Bug 301649 Build ID: 2005-07-21-06, Windows XP SP2 SeaMonkey trunk.

Overview: When an HTML-formatted message contains and invalid filename (i.e.
non-existing), and this email message is forwarded inline, on send SeaMonkey
Mail spins indefinitely, 'Attaching filename.gif...'

Steps to Reproduce:

1. Load and select/view the attached .eml file in SeaMonkey Mail.
2. Choose Message -> Forward As -> Inline from the top-level menu.
3. Click Send.

Expected Results:
As in Thunderbird 0.9, I'd expect "There was a problem including the file
filename.gif in the message.  Would you like to continue sending the message
without this file?"
(OK) (Cancel)

Actual Results:
We spin saying "Attaching filename.gif...""

"Verified FIXED in version 1.6a1 (20050917) of Thunderbird trunk and SeaMonkey
1.1a:Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050917
Mozilla/1.0"

The behavior of the system in the above bug is strikingly similar to that of the bugs under discussion.  The above bug either wasn't fixed,  wasn't completely fixed or had an underlying cause.  While investigating this problem I also discovered another Bug, 317970, with is also similar to the named bugs and which was thought to be a duplicate of Bug 324110.

"Bug 317970  Description:  [reply]  	 Opened: 2005-11-27 21:10 PDT
------------------------------------------------------------------------------------------------------
With SeaMonkey trunk CVS I was copmosing an email.  I have the "automatically
save every x minutes" pref enabled and when it tried to do so, it hung.  After
restarting, I pulled up the draft (saving seemed to be successful) and sent it
and I got another hang.  I was using a debug build and got this both times:

CopyListener::OnStartCopy()
nsMsgComposeSendListener::OnStartCopy()
CopyListener: SUCCESSFUL ON THE COPY OPERATION!
nsMsgComposeSendListener: Success on the message copy operation!
[hang]

------ Comment #16 From Adam Guthrie  2006-01-20 12:36 PDT  [reply] -------
*** Bug 324110 has been marked as a duplicate of this bug. ***"

I believe that there is a reasonable probability that bugs:
301649
317970
319818
324110
either are the same bug, manifestations of the same bug, or have a common root cause.  If they were solved earlier, they wouldn't be problems now.

It therefore seens reasonable that the four different bugs be combined into a single bug and their votes be likewise combined.

Respectfully submitted,
Charles Faulk, MD

Comment 18

[Mike Cowperthwaite]

Agree on the dupe.

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