User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 Build Identifier: version 1.6a1 (20051209) Suppose a html mail in the draft box with images inserted. When we open it to edit it again, we can save the mail one first time, but if we try to save it a second time, it hangs in the phase of "attaching". We can cancel, or we can wait a (very) long time until the application quits. If the save is triggered by the auto-save, we can only do the second. Either way, we can only save if we previously delete all the images of the original message. If we insert them at that editing session, there are no problem. Reproducible: Always Steps to Reproduce: 1. Do an html mail message with inserted pics, save and close 2. Open to edit (souble click) the mail, edit it or not, save the mail 3. Try to save the second time (or save in the close of it). Alternative: set the auto-save and try to work on the mail for the time enouth to save twice. Actual Results: The html mail composer hangs while trying to "attach". We can cancel or close the window, but not work on it until the application quits from trying to attach. It never do. Expected Results: The composer saves the mail, with the images... The problem was first detected on a T1.5RC and confirmed on a 1.6a1. It occurs with and without extensions, with a old or a new profile. It doesn't occur with Mozilla 1.6, Netscape 7.2 or Thunderbird 1.0.7, or with attached images. It only happens with the original images inserted in the old mail to reedit. If they are deleted and reinserted again, we can save them all the times we wanted. The file paths doesn't have any kind of weird chars. With enough patience is a nuisance which can be overcamed, without it, we'll loose all the last editings. I'll classify it as a normal bug, but some others will probabily consider it a critical bug as it can lead the imprepared to loose data. My system is a AMD Duron +1800, 1Gb Ram, XP Prof. SP1.

I just confirmed now: the problem persists on the 1.5 RC2 too. Also, I extendend the test to a second machine with a W2000 prof.. A fresh installed 1.5RC2 where the previous T1.0 was uninstalled. The problem exists there too. regards, JPA

Confirmation and test of different versions on Windows XP an Linux: I confirm this bug. I tested different versions of Thunderbird and Mozilla on Windows XP and Linux. On Windows XP I always made fresh install of Thunderbird or Mozilla after uninstalling previous version. I always tryed to reproduce the bug with new profile. On Linux I always ran Thunderbird or Mozilla with new profile. All tests are made on Thunderbird or Mozilla without extensions. Results are listed below. Results: Linux OpenSuSE 10.0: - Mozilla 1.7.13 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060417 = DOESN'T HAVE THE BUG - Thunderbird 1.0.7 (20050923) = DOESN'T HAVE THE BUG - Thunderbird 1.5rc2 (20051201) = HAS THE BUG - Thunderbird 1.5.0.2 (20060420) = HAS THE BUG - Thunderbird 1.5.0.4 (20060508) = HAS THE BUG - Thunderbird 3 alpha 1 (20060514) = HAS THE BUG Microsoft Windows XP Professional - version 5.1.2600 Service Pack 2 Build 2600: - Mozilla 1.7.12 [Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915] - DOESN'T HAVE THE BUG - Mozilla 1.7.13 [Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414] - DOESN'T HAVE THE BUG - Thunderbird 1.0.7 (20050923) = DOESN'T HAVE THE BUG - Thunderbird 1.5 (20051201) = HAS THE BUG - Thunderbird 1.5.0.2 (20060308) = HAS THE BUG - Thunderbird 1.5.0.4 (20060508) = HAS THE BUG - Thunderbird 2 alpha 1 (20060514) = HAS THE BUG - Thunderbird 1.5rc2 (20051201) = HAS THE BUG - Thunderbird 3 alpha 1 (20060511) = HAS THE BUG - Thunderbird 1.0.8 (20060514) = DOESN'T HAVE BUG I suggest to change severity to higher one (becouse of AutoSave alternative) I also found similar bug report: 324110 and maybe bug reports: 335218 and 325340 With regards mxxxm.

Similarly confirmed here with Thunderbird 1.5.0.4 on Windows XP (Thunderbird 1.5.0.4 (Windows/20060516)) with the autosave option turned on (how I stumbled across this bug). Surely the status should be changed to NEW from UNCONFIRMED by now?

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 this confirms 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. 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. Maybe a new bug? I have also reviewed bug #324110 (which has a severity of 'blocker') and I agree with mxxxm@volny.cz that both bugs are probably the result of the same core problem and that the severity should be increased to 'blocker' since this bug(s) affect at least the composition, sending and receiving of message files. Respectfully submitted, Charles Faulk MD

Correction to Comment #4: Bug 324110 has severity of 'critical', not 'blocker'. Sorry.

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 mxxxm@volny.cz 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

Reproduced with TB 1.5.0.7, 3a1-0915, SM 1.5a-0817, Win2K.

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

See also bug 343933.

In bug #324110, comment 14 (https://bugzilla.mozilla.org/show_bug.cgi?id=324110#c14) I talked about the composer window being unresponsive during the time autosave is performed. I quote: > 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? Futher on in the comment I demonstrated that under what would appear as rather benign conditions, five keystrokes were "swallowed" while autosave was performed on an IMAP account. Probably a rather arbitrary test, but I still hope it helps to illustrate the problem. But I am actually unsure whether this is actually related to the phonemon described in the bug. Can I wait for a solution to this bug, or should I open a new one?

I just encountered an older bug for this same problem, duping. Please move your votes to that bug. (In reply to comment #10) > But I am actually unsure whether this is actually related to the phonemon > described in the bug. Can I wait for a solution to this bug, or should I > open a new one? That's pretty definitely a different symptom, since the window becomes responsive after the save has completed. In this bug, the window never becomes responsive. See bug 304026: you can change the Drafts folder for your IMAP account to point to a Local Folder instead, which should make the process of saving much quicker. *** This bug has been marked as a duplicate of 271707 ***

Reopening, this isn't exactly a dupe.

this worked fine for me for imap, but local failed as you described. I suspect these errors might be involved THE CLEANUP ROUTINE FOR nsMsgComposeAndSend() WAS CALLED Security Error: Content at about:blank may not load or link to about:blank. Security Error: Content at about:blank may not load or link to mailbox:///C|/Doc uments%20and%20Settings/username/Application%20Data/Thunderbird/Profiles /xxxx.default/Mail/Local%20Folders/Drafts?number=2713431&part=1.2&filename=W ater%20lilies.jpg.

I'm not using IMAP. I'm using Thunderbird 3 Alpha 1 (Trunk nightly) on Windows XP, but I've experienced a problem with inline images in earlier versions too. I don't think any of the technical workarounds suggested should be necessary. People should be able to put images in a new message, see them display, save a draft, go back to it, add text, and send the message. At present added images display erratically, causing people to Save, check the Drafts folder to see whether the images have in fact appeared, and then edit the draft. Using the draft causes the "attaching" problem. I'm not convinced that all images actually get sent, even if you don't do any saving and re-editing. I'm pretty sure I have sent messages directly in the past and the images have not arrived. Sometimes I've done it several times over before putting an image on the internet and taking it from there instead (that always works). Best wishes Peter

I have the same problem for quite some time now. Current situation : TB 1.5.0.8. / Win-XP Pro SP 2 / POP3 mail. When inserting an image from local disk into a html mail, I often just get an image marker but not the actual image. When sending such a mail, the image is not received. On a few occasions though less frequent, the attaching problem occurs.

I've just solved the problem I was having with a similar issue based on the advice in this post: http://forums.mozillazine.org/viewtopic.php?p=2622611&sid=461495a4fdde1a6763283068ab863e9c Briefly, try this: (1) Add your own email address to your address book. (2) In the entry for your name, click the box "Allow remote images in HTML mail". (3) Close and reopen TB. (4) Don't hate me if it doesn't work. By the way, in my experience, the images were always sent. The problem was that I was only getting the image holder (red dot) in my compose window.

(In reply to comment #16) > By the way, in my experience, the images were always sent. The problem was > that I was only getting the image holder (red dot) in my compose window. Then you weren't experiencing this bug. That sounds like bug 343933.

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

I see this problem sporadically in Seamonkey 1.0.7 under XP and imap, particularly when opening an old message with embedded remote graphics, editting the message a bit and then resending it. I get a wait message that says "Attaching" and never actually sends. Other times, trying to do the same thing, it goes through fine.

I am experiencing the exact same issue with TBird V2 B1 20061206 on XP Pro SP2.

Running TB version 2 beta 2 (20070130) on WIN xp Home. Inserting a graphic image from WIN clipboard into a new compose window doesn't work every times. Same with D&D a image (jpg-file). Same situation as above with C # 19: "When inserting an image from local disk into a html mail, I often just get an image marker but not the actual image." Storing as a draft, reopening shows image correclty. But also the situation as with C # 19 is true: "I get a wait message that says "Attaching" and never actually " ... finshed storing back to Draft.

(In reply to comment #21) > Inserting a graphic image from WIN clipboard into a new compose window doesn't > work every times. Same with D&D a image (jpg-file). Same situation as above > with C # 19: Yeah -- and like the poster of comment 19, you didn't bother to read comment 16 and comment 17, which point out that *that symptom is a different bug*. And as it happens, *that* bug has been fixed as of two days ago. Apparently, it can never be stated often enough: comments to the effect of "I'm seeing this bug" are NOISE. Stop making such comments.

@MIKE !!! (In reply to comment #22) > And as it happens, *that* bug has been fixed as of two days ago. As of TODAY=2007-02-06 and running version 2 beta 2 (20070205) is still HAS the some behavior / bug! > > Apparently, it can never be stated often enough: comments to the effect of > "I'm seeing this bug" are NOISE. Stop making such comments. > Is it NOISE to point out a beta/Pre has NOT fixed a bug? I fully respect all the work these people here are doing and I fully understand those "comments" take your time, but how should an engaged user make comments if not here ? Do you prefer private mails? I'm sure : NO!

The duplicate sees what's apparently the same issue with background images on the HTML body.

When we save the draft for the 2nd time...when we fetch the attachment part for the image we run a mailbox url that looks like: mailbox:///C|/Documents%20and%20Settings/mscott/Application%20Data/Thunderbird/Profiles/default/e0tp69e8.slt/Mail/Local%20Folders/Drafts?number=254755&part=1.2&filename=moz-screenshot-9.jpg And in nsMailboxProtocol::Initialize, we try to get the message size for this part and get back a value of 0: http://lxr.mozilla.org/mozilla/source/mailnews/local/src/nsMailboxProtocol.cpp#199 I think that's causing the spin. Another interesting data point, the first time I save the message as a draft, the mailbox url we run when we fetch the part looks like: mailbox:///C|/Documents%20and%20Settings/mscott/Application%20Data/Thunderbird/Profiles/default/e0tp69e8.slt/Mail/Local%20Folders/Drafts?number=396124&part=1.2 I'm not sure why it's different the 2nd time we save as a draft.

Actually, it looks like the 2nd time we save, the message header we get for the mailbox url we are running says the message size is 0 in SetupForExtraction: http://lxr.mozilla.org/mozilla/source/mailnews/local/src/nsMailboxProtocol.cpp#427 I wonder if the problem really isn't with the 2nd save but with how the msg hdr gets updated after the initial save.

very strange - the msg hdr's m_messageSize member variable is right, but the mork column has a value of 0 - not sure how those two got out of sync.

OK, I think that's because the msg hdr is the msg hdr for the previous version of the draft message - it's had its mork row cleared out, because the header has been removed. But somehow the msg url has the wrong header, perhaps because it has the wrong msg key? I'll have to step through the code that figures out the msg hdr.

OK, I think the problem is that the url for the images is set when we edit the draft message. After we save the draft message, that url is no longer correct, because the msg key for the message has changed!

see comments in diff...

Comment on attachment 257181 [details] [diff] [review] proposed fix David, should we bypass ResetUrisForEmbeddedObjects altogether for imap?

fixed on branch - I make ResetUrisForEmbeddedObjects do an early return for the imap case. I'll attach the patch in a second. I'm trying to get this to compile on the trunk.

fixed on trunk.

flag cleanup.

V fixed with 2pre-0306, Win2K

verified fixed 1.8.1.3 using the steps to reproduce in this bug and Thunderbird 2 RC 2 Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.0 ID:2007032620

I'm afraid the bug still exists in Thunderbird/2.0.0.0. The steps to reproduce (Windows XP, SP2): 1. Open the composer window and type some text. 2. Insert an image from disk or clipboard. 3. Save the message and close the window. 4. Re-open the message. It looks fine. 5. Drag and drop the image to another location in the text. The image disappears, only the frame remains visible. 6. Click "Save" or "Send". Two windows appear, one of them shows a running progress bar ("Attaching..."), another is a standard MessageBox that says, "Unable to save your message as draft (or Sending of message failed). There was an error attaching. Please check if you have an access to the file." Also I encountered another interesting effect, probably caused by the same error. The steps to reproduce: 1 - 4. As above. 5. Insert ANOTHER image BEFORE the existing image. All looks OK. 6. Click "Save". Instead of the old image, you will see the new image stretched to the dimensions of the old one!

Yep, comment 42 is right; the core problem wasn't fixed, just one of the triggers. On reopening the message the first time, the 'src' attribute is showing the bad '&' unescape problem; this is copied from the Insert|HTML window: mailbox:///D%7C/<path>/Drafts?number=214190&amp;part=1.2&amp;filename=pic.jpg ~~~~~ ~~~~~ And the extra symptoms on the second image, described in the last paragraph of comment 42, also occur as described. Has another bug already been opened for these somewhere? If not, there are two symptoms here that require two new bugs.