Closed Bug 790230 Opened 12 years ago Closed 10 years ago

attaching signature with inline image hangs up thunderbird

Categories

(Thunderbird :: Message Compose Window, defect)

15 Branch
x86
Windows 7
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 532395

People

(Reporter: esnyder, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: hang)

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20100101 Firefox/15.0 Build ID: 20120824154833 Steps to reproduce: I try to type an e-mail message and Thunderbird hangs all the time. Actual results: I have an HTML e-mail signature with an image in it. Whenever I am composing messages Thunderbird will stop accepting input and a message at the bottom of the window says "...attaching e-mail signature". The text which is typed when Thunderbird hangs does not always show up when Thunderbird becomes responsive again. This is an incredibly annoying bug. I just don't understand why it happens multiple times during composition and then again when I click the send button. Expected results: Thunderbird should never hang while typing. Thunderbird should be able to do more than one thing at a time. Thunderbird should NOT try to attach an e-mail signature during composition of the e-mail, it should only do it at send time. Clearly whoever wrote the code does not understand that they are interrupting the ability to use the software.
If you remove the image from the signature, does it work alright then? Inline images, due to the wrong way in which TB handles them (initially inserting URL instead of raw data), are a frequent culprit... Suppose it's about time somebody looked into that because we are getting more and more reports every day...
When I remove the img tag from the html it instantly gets added to my e-mail and I do not see it hang at all. So, the e-mail is being rendered as html and it's displaying the image in the image tag in the html signature file prior to sending? Then Thunderbird is actually embedding the data into the e-mail for sending? Why doesn't Thunderbird wait to do that after the send button has been clicked? Thanks for looking into this.
for the hang could we get a stack trace , to understand whihc part of the code is the cumprit ?
Keywords: hang
You'll have to provide me with instructions to get the stack trace... Not sure how to do this.
I hate it when you go to debug and then are unable to reproduce the issue. Maybe if I hadn't changed the signature file. Thunderbird doesn't cache signature files right? Waiting for it to happen again...
For a less technical approach (and assuming that this is the type of hang which simply results from not-found parts): Pls file code snippet how the picture is included in the signature file: <img src="C:\local path\img.png"> OR <img src="data:..."> OR ? Follow these steps: 1 compose with signature 2 Ctrl+S to save draft (if that fails already, check if the img really exists) 3 close draft (important!) 4 reopen draft (Edit...) 5 double-click on image in signature 6 From Image Properties dialogue, report "Image Location" URL here (In reply to esnyder from comment #0) > Actual results: > I just don't understand why it happens multiple times during composition and > then again when I click the send button. That's Autosave feature, check your settings here: Tools > Options > Composition > General > [x] Autosave every [5] mins > Expected results: > Thunderbird should never hang while typing. Thunderbird should be able to > do more than one thing at a time. Obviously yes ;) > Thunderbird should NOT try to attach an > e-mail signature during composition of the e-mail, it should only do it at > send time. I disagree. In fact, if Thunderbird would attach things immediately and include the image source as a data URL, we would not have any problems. Currently we have a very complex and UX-unpredictable and error-prone way of attaching those parts. > Clearly whoever wrote the code does not understand that they are > interrupting the ability to use the software. Let's assume they wrote code to their best knowledge within the circumstances, but it's possible they overlooked something which with the benefit of hindsight has turned out to be a problem now.
Thomas, I appreciate your responses. Thank you. Very concise. Hopefully I am following your instructions correctly. Here's the html: <img src="file:///C:/Users/esnyder/Documents/MailSignature/email_sig_sm.jpg" moz-do-not-send="false"> Here's the image location from Thunderbird: file:///C:/Users/esnyder/Documents/MailSignature/email_sig_sm.jpg
Thomas, you seem to be on top of the history of this problem. Is this bug a dup? Is there any reason that you have not either confirmed it, or dupped it? Is the assumption of the root cause here that file access is slow, and therefore the UI hangs waiting for the file to be read?
(In reply to Kent James (:rkent) from comment #9) > Thomas, you seem to be on top of the history of this problem. Is this bug a > dup? Is there any reason that you have not either confirmed it, or dupped it? Hi Kent, thanks for requesting clarification. I suspect that this is a dupe of Bug 532395 (or its sibling Bug 468159 which imo is a dupe of Bug 532395 but Wada disagrees because there's no 100% proof that same symptoms confirmed in various comments have same cause). I've come across a lot of old and recent bugs involving inline images recently (e.g. similar Bug 766495), and I suspect we have a number of bugs where inline images play a role but it has not yet been identified. But until old bad bugs like bug 532395 are fixed, we have no way of verifying if same symptoms are caused by this problem. > Is the assumption of the root cause here that file access is slow, and > therefore the UI hangs waiting for the file to be read? It's not my assumption, but it's possible. Historically, I'm coming from structurally similar Bug 378046 comment 60, which is one of the very first bugs I filed on bmo in 2007. I still think it's a pretty bad old bug which would deserve a lot more attention than it gets. But there was a lot of noise of users who don't understand the problem because it's a complex thing. In the same line, there's bugs like Bug 391190 and Bug 531354. The logical connection between all of these aforementioned bugs is that instead of attaching "the real thing" immediately and ensuring it cannot be altered, exchanged or otherwise go away, we rely on fragile URLs to included original parts which we then collect, convert and embed at an unpredictable point of time. We even end up attaching wrong parts if the original gets replaced by new content and the temporary pointer URL still happens to work (e.g. badly breaking privacy in bug 378046, or attaching wrong images in Bug 766495). Talking about it, perhaps this logical/structural problem is ripe for a meta-bug, what do you think? Btw I completely agree with your point on tb-planning that it's more than frustrating that we're just identifying and QA-preparing so many bugs until they are ready to be fixed, and then nobody bothers to fix them for years and we continue managing complex dupes ever after...
Summary: attaching signature hangs up thunderbird → attaching signature with inline image hangs up thunderbird
I think WADA also sees the common pattern of bugs mentioned in comment 10, see his Bug 391190 Comment 2 (although I'm not sure if the solution proposed there works). Solutions are not always easy to find. Some ideas in Wada's Bug 532395 Comment 62. For the case of inline images, imo the best solution is to immediately and consistently embed them as data-URLs, which we already do for some cases of images pasted into composition.
OK thanks Thomas for the clarification. Bugs need to morph from symptom-focused to solution-focused over their life. I see 2 independent classes of solutions that both need implementing: 1) Don't hang when the URL read is slow or fails 2) Prevent the URL from failing. This could be your "immediately and consistently embed them as data-URLs" or find each individual issue and solve it. I certainly agree that it is pointless to parse bugs ever more finely if there is no commitment to ever look at them. I would be happy to dup a little more aggressively, we can always undup later if we are really going to address this. For the larger issue of bug management, I think that it was clear that QA feels it is pointless to maintain lists of bugs needing fixing if there is no commitment to address those bugs. OK I hear that, so we have one existing list (the 10 papercuts bugs list) so let's prove that we can move forward with those before we ask any more of QA. But this has to wait until post TB 17. In the long run, I would really like to figure out a way to empower regular BMO editors such as yourself to get attention paid to bugs, perhaps by asking you to maintain your own list of say 10 bugs that you want to get attention that becomes part of a larger list of around 100 bugs that we would all agree we need to attack.
See Also: → 532395
(In reply to esnyder from comment #0) > Actual results: > I have an HTML e-mail signature with an image in it. > Whenever I am composing messages Thunderbird will stop accepting input and a message at > the bottom of the window says "...attaching e-mail signature". (In reply to esnyder from comment #8) > Here's the html: > <img src="file:///C:/Users/esnyder/Documents/MailSignature/email_sig_sm.jpg" moz-do-not-send="false"> Where was the img tag for your signature obtained? - Identity setting : Signature text, Use HTML - Identity setting : Attach the signature from file - Identity setting : Attach my vCard - Message source of Sent mail copy, Saved draft etc. - other As for "composing started with <img src="file:///C:/..."> of existent image file" case or image location=file:///C:/..., case, loss of image file, loss of old draft mail, never produces phenomenon of "...attaching e-mail signature". It simply produces phonomenon of Bug 391190. Because Tb knows about original file:///C:/... and image location is file URL through out the mail composing, symptom of Bug 532395, endless "...Attaching" with "Unable to save as draft" or "Unable to send" message, won't occur. Symptom of Bug 532395, endless "...Attaching" with "Unable to save as draft" or "Unable to send" message, occurs only when mail with image location=file:///C:/... is saved as draft or as sent mail copy and image location is changed to mailbox:///C:/ ... /FolderName?number=6202&part=1.2 like one. Bug opener, what is actual "steps to reproduce" of your problem? Does your "Whenever I am composing messages" mean "only when Editing draft or Forwaring mail"?
I used attach a signature from "a file instead" and the file contains that HTML element. As for when it happens. The behavior happens while I am typing the e-mail. All of a sudden Thunderbird stops accepting input and then it returns and doesn't display what I typed, it doesn't remember and catch up, it just drops new text. Regardless of whether I am replying or starting a new e-mail this can happen at seemingly random times. I've also seen something like this happen and then Thunderbird asks if I want kill some Google script.
(In reply to WADA from comment #13) > (In reply to esnyder from comment #0) > > Actual results: > > I have an HTML e-mail signature with an image in it. > > Whenever I am composing messages Thunderbird will stop accepting input and a message at > > the bottom of the window says "...attaching e-mail signature". > (In reply to esnyder from comment #8) > > Here's the html: > > <img src="file:///C:/Users/esnyder/Documents/MailSignature/email_sig_sm.jpg" moz-do-not-send="false"> > > Where was the img tag for your signature obtained? > - Identity setting : Signature text, Use HTML > - Identity setting : Attach the signature from file > - Identity setting : Attach my vCard > - Message source of Sent mail copy, Saved draft etc. > - other > > As for "composing started with <img src="file:///C:/..."> of existent image > file" case or image location=file:///C:/..., case, loss of image file, loss > of old draft mail, never produces phenomenon of "...attaching e-mail > signature". > It simply produces phonomenon of Bug 391190. > Because Tb knows about original file:///C:/... and image location is file > URL through out the mail composing, symptom of Bug 532395, endless > "...Attaching" with "Unable to save as draft" or "Unable to send" message, > won't occur. > Symptom of Bug 532395, endless "...Attaching" with "Unable to save as draft" > or "Unable to send" message, occurs only when mail with image > location=file:///C:/... is saved as draft or as sent mail copy and image > location is changed to mailbox:///C:/ ... /FolderName?number=6202&part=1.2 > like one. > > Bug opener, what is actual "steps to reproduce" of your problem? > Does your "Whenever I am composing messages" mean "only when Editing draft > or Forwaring mail"? I used attach a signature from "a file instead" and the file contains that HTML element. As for when it happens. The behavior happens while I am typing the e-mail. All of a sudden Thunderbird stops accepting input and then it returns and doesn't display what I typed, it doesn't remember and catch up, it just drops new text. Regardless of whether I am replying or starting a new e-mail this can happen at seemingly random times. I've also seen something like this happen and then Thunderbird asks if I want kill some Google script.
(In reply to esnyder from comment #15) > As for when it happens. The behavior happens while I am typing the > e-mail. All of a sudden Thunderbird stops accepting input and then it > returns and doesn't display what I typed, it doesn't remember and catch up, it just drops new text. When the phenomenon occurred, how about "...attaching e-mail signature" status bar message? How long was the "...attaching" message shown? > Whenever I am composing messages Thunderbird will stop accepting input > and a message at the bottom of the window says "...attaching e-mail signature". How log does it take usually to save composing mail with the image signature in your environment? (0) Disable auto-save. At Accunt Settings/Copis&Folders, Check "Show confirmation dialog when messages are saved". (1) Open mail composition window, as you usualy do. (2) Type Subject, fill message body text, as you usualy do. (3) Save as draft. How long does it take? (4) Repeat "Modify subject, Save as draft" several times. How long does it take? When did your problem start to occur? After upgrade to specific Tb release? Does your problem occur with Tb's safe mode? thunderbird.exe -safe-mode or, Help/Restart with Add-ons Disabled Do you use lightning?
(In reply to esnyder from comment #8) > Here's the html: > <img src="file:///C:/Users/esnyder/Documents/MailSignature/email_sig_sm.jpg" moz-do-not-send="false"> (In reply to esnyder from comment #15) > I used attach a signature from "a file instead" and the file contains > that HTML element. Is signature file content the <img> tag only? Or many other HTML tags are contained and a <img> tag only is shown as signature image in composed mail? (In reply to esnyder from comment #15) > As for when it happens. The behavior happens while I am typing the > e-mail. All of a sudden Thunderbird stops accepting input and then it > returns and doesn't display what I typed, it doesn't remember and catch up, it just drops new text. Phenomeon is following? - While typing, typed text is shown, (highlighted?) - Then Tb stops accepting input, - Then Tb stops accepting input, as if freezing - After a while, short freeze ends, and typed txt is lost If so, do you use IME? (e.g. Input Method like MS-IME for Kana-Kanji-Henkan)
(In reply to esnyder from comment #0) > Thunderbird should NOT try to attach an e-mail signature during composition of the e-mail, it should only do it at send time. Does it imply that you tried to change image file content used as your signature(i.e. Write open or lock file by Photoshop or something) while you are composing a mail using the image file as your signature?
(In reply to WADA from comment #16) > (In reply to esnyder from comment #15) > > As for when it happens. The behavior happens while I am typing the > > e-mail. All of a sudden Thunderbird stops accepting input and then it > > returns and doesn't display what I typed, it doesn't remember and catch up, it just drops new text. > > When the phenomenon occurred, how about "...attaching e-mail signature" > status bar message? How long was the "...attaching" message shown? > > Whenever I am composing messages Thunderbird will stop accepting input > > and a message at the bottom of the window says "...attaching e-mail signature". > > How log does it take usually to save composing mail with the image signature > in your environment? > (0) Disable auto-save. > At Accunt Settings/Copis&Folders, > Check "Show confirmation dialog when messages are saved". > (1) Open mail composition window, as you usualy do. > (2) Type Subject, fill message body text, as you usualy do. > (3) Save as draft. How long does it take? > (4) Repeat "Modify subject, Save as draft" several times. > How long does it take? > > When did your problem start to occur? After upgrade to specific Tb release? > > Does your problem occur with Tb's safe mode? > thunderbird.exe -safe-mode > or, Help/Restart with Add-ons Disabled > Do you use lightning? First time I saved a draft - normal behavior - took a few seconds, after that, more or less instant. The 'lock-up' behavior is completely intermittent. I will do my best to time it the next time it occurs. I've had auto-save disabled since this was first reported. I'm not sure which version is started on, but I'm running 17.0.5 now. I've never tried safe mode in Thunderbird. I don't run with any add-ons in Thunderbird. I do not use Lightning.
(In reply to WADA from comment #17) > (In reply to esnyder from comment #8) > > Here's the html: > > <img src="file:///C:/Users/esnyder/Documents/MailSignature/email_sig_sm.jpg" moz-do-not-send="false"> > (In reply to esnyder from comment #15) > > I used attach a signature from "a file instead" and the file contains > > that HTML element. > > Is signature file content the <img> tag only? > Or many other HTML tags are contained and a <img> tag only is shown as > signature image in composed mail? > > (In reply to esnyder from comment #15) > > As for when it happens. The behavior happens while I am typing the > > e-mail. All of a sudden Thunderbird stops accepting input and then it > > returns and doesn't display what I typed, it doesn't remember and catch up, it just drops new text. > > Phenomeon is following? > - While typing, typed text is shown, (highlighted?) Yes, but not highlighted. > - Then Tb stops accepting input, Yes and the attaching signature message shows up in the bottom of the screen. > - Then Tb stops accepting input, as if freezing Yes. > - After a while, short freeze ends, and typed txt is lost Anything typed during the apparent lock-up is lost. > If so, do you use IME? (e.g. Input Method like MS-IME for Kana-Kanji-Henkan) I don't know what these are... The img tag is the last tag in the file. It contains font, br, i, a, and the img tags and some text. Nothing else other than the anchor tags reference anything outside of the file and the anchors are merely references.
(In reply to WADA from comment #18) > (In reply to esnyder from comment #0) > > Thunderbird should NOT try to attach an e-mail signature during composition of the e-mail, it should only do it at send time. > > Does it imply that you tried to change image file content used as your > signature(i.e. Write open or lock file by Photoshop or something) while you > are composing a mail using the image file as your signature? Nothing is reported back other than the "attaching e-mail signature" message.
(In reply to esnyder from comment #21) > (In reply to WADA from comment #18) > > (In reply to esnyder from comment #0) > > > Thunderbird should NOT try to attach an e-mail signature during composition of the e-mail, it should only do it at send time. > > Does it imply that you tried to change image file content used as your > > signature(i.e. Write open or lock file by Photoshop or something) while you > > are composing a mail using the image file as your signature? > Nothing is reported back other than the "attaching e-mail signature" message. ??? What does your answer mean? I simply asked you about status of image file used as your signature file, asked you about your action on the image file used as your signatur...
(In reply to WADA from comment #22) > (In reply to esnyder from comment #21) > > (In reply to WADA from comment #18) > > > (In reply to esnyder from comment #0) > > > > Thunderbird should NOT try to attach an e-mail signature during composition of the e-mail, it should only do it at send time. > > > Does it imply that you tried to change image file content used as your > > > signature(i.e. Write open or lock file by Photoshop or something) while you > > > are composing a mail using the image file as your signature? > > > Nothing is reported back other than the "attaching e-mail signature" message. > > ??? > What does your answer mean? > I simply asked you about status of image file used as your signature file, > asked you about your action on the image file used as your signatur... Sorry, your question wasn't clear and still isn't... You asked: "Does it imply that you tried to change image file content used as your signature(i.e. Write open or lock file by Photoshop or something) while you are composing a mail using the image file as your signature?" Thunderbird doesn't "imply" anything to me. The files isn't being used by any other software and hasn't been altered in over six years. As I stated in my previous response the only notification I receive from Thunderbird is that it is attaching a signature to the e-mail.
(In reply to esnyder from comment #19) > First time I saved a draft - normal behavior - took a few seconds, > after that, more or less instant. It's perhaps diferrence betwen "first image file read==data is not held in disk cache of OS yet" and "second or later image file read==data is already held in disk cache of OS". What is file size of image file used as your signature? (In reply to esnyder from comment #23) > As I stated in my previous response the only notification I receive from > Thunderbird is that it is attaching a signature to the e-mail. Is the notification from Tb, "attaching a signature to the e-mail", status bar message? Or dialog? Was the notification from Tb kept forever? Or cleared after you experienced loss of typed text after a short freeze? Anyway, it sounds problem when auto-save is invoked while typing, what is already known issue(accept nothing while auto-save, as if freeze), instead of problem during attaching image signature. i.e. Bug summary is sufficiently confusing and misleading. Do following in daily use. (1) At Copies&Folders setting, check next option. [ x ] Show confirmation dialog when messages are saved. (2) As you did do, enable auto-save. By (1), when auto-save is invoked and draft is saved, dialog is shown. So, new notification from Tb of "auto save ended" will be obtained.
FYI. About "when image file pointed in by file:// URL in HTML signaure is read". (1) During new mail composition. (1-1) Upon first drat save, image file is read, and held in OS's disk cache. A few second in your environment. Image data is writen as subpart under multipart/related in draft, and file:// URL is changed to cid: URL in draft. (1-2) Upon second or later drat save, image file data is read from OS's disk cache. So, istantly in your environment. Image data is writen as subpart under multipart/related in draft, and file:// URL is changed to cid: URL in draft. (1-3) Upon Send Later and Send, or Save as Draft and exit composition, image file data is read from file. If no "draft save" occurs, it takes a few second in your case. Image data is writen as subpart under multipart/related in temporary file, and file:// URL is changed to cid: URL in draft. If Send Later, temp file is saved in Outbox of Local Folders, and if Send, data in temp file is passed to SMTP server, and if Save as Draft and exipt composition, save in Drafts. (2) When Edit Draft, or Forward Inline/Edit As New of existent mail, "cid: URL" and "image subpart wth Content-ID: under multipart/related" is used by Tb. In this case, image signature in referred mail is used by Tb. So, problem like bug 453196 and bug 817245 may happen. If option of "Add signature in Forward" is used, image signature is added by "Forward Inline", so same thing as (1) occurs on this newly added signature from your HTML sinature file.
(In reply to WADA from comment #24) > (In reply to esnyder from comment #19) > > First time I saved a draft - normal behavior - took a few seconds, > > after that, more or less instant. > > It's perhaps diferrence betwen "first image file read==data is not held in > disk cache of OS yet" and "second or later image file read==data is already > held in disk cache of OS". > What is file size of image file used as your signature? > The image is 71 kb. > (In reply to esnyder from comment #23) > > As I stated in my previous response the only notification I receive from > > Thunderbird is that it is attaching a signature to the e-mail. > > Is the notification from Tb, "attaching a signature to the e-mail", status > bar message? Or dialog? It shows up in the status bar. Lately I've seen the behavior without the notification too... > Was the notification from Tb kept forever? Or cleared after you experienced > loss of typed text after a short freeze? > When Thunderbird becomes responsive again, the notice in the status bar goes away. > Anyway, it sounds problem when auto-save is invoked while typing, what is > already known issue(accept nothing while auto-save, as if freeze), instead > of problem during attaching image signature. > i.e. Bug summary is sufficiently confusing and misleading. > > Do following in daily use. > (1) At Copies&Folders setting, check next option. > [ x ] Show confirmation dialog when messages are saved. Already checked. > (2) As you did do, enable auto-save. > By (1), when auto-save is invoked and draft is saved, dialog is shown. So, > new notification from Tb of "auto save ended" will be obtained. OK.
I have got a similar behaviour upon replying to a message *with an image in the signature*. The image was not accessible to me, so the message was displayed with a placeholder. Upon sending the the reply however TB got stuck in an infinite loop with message "Attaching...". To reproduce: send a message with a HTML image in the signature pointing to a remote resource to a friend, who won't have acces to that remote resource. After that, let him reply to that message. He will get stuck in an infinite loop with message "Attaching...". Workaround: delete all placeholders in the sig. Regards.
I had this issue. I applied a workaround of converting my signature image to a data URI and using that in my signature file. I used the service at... http://websemantics.co.uk/online_tools/image_to_data_uri_convertor/ On sending, the embedded image was extracted by Thunderbird and attached to the email as a file. Obviously I'm not recommending this as a solution, it's just a workaround, but it may also help determine the problem.
I have constant "Attaching..." stalls with embedded images in Thuderbird. Most seem to be when replying to other emails with embeds. Just a week ago I added an embedded image in my sig and I am seeing this about every 30th email. I just cancel the send delete the image in the attachment and it send fine. Again, I think that this is a generic "embedded image" issue, not one specific to sigs. I use embedded images religiously, so if you need me to help testing / stack tracing, I would be happy. Running 29.0a2 on Windows 7 64.
To all problem reporters in this bug, except bug opener of this bug: What is difference of your problem from already known(and not resolved yet) bug 817245/bug 453196, or bug 532395? (exclude this bug from (c), please) Note: bug 532395 == (a) bug 817245, bug 453196 + (b) bugs listed in dependency tree for (a) + (c) some bugs listed in dependency tree for meta bug 877159 + (d) different problem from (a), (b), (c)
No idea about https://bugzilla.mozilla.org/show_bug.cgi?id=817245. I do not believe that https://bugzilla.mozilla.org/show_bug.cgi?id=453196 applies since we are not deleting the original. I think that my issue is exactly like https://bugzilla.mozilla.org/show_bug.cgi?id=532395. Note that I think all sufferers of this issue are on IMAP4. Again, this particular thread is about sigs, but I think that actual issue here is more generic to IMAP4 and embeds, and this bug is probably a dup of https://bugzilla.mozilla.org/show_bug.cgi?id=532395. -Brian
(In reply to bhendel from comment #31) > I think that my issue is exactly like bug 532395. > this bug is probably a dup of bug 532395. If so, because bug 532395 is merely a chaos, this bug and your report is merely an newly added "Me too only comment" which won't help problem analysis and Tb's bug resolving :-) Bug 532395 is intentionally kept open even after problem of bug 817245 & bug 453196 are clearly/cleanly separated from Bug 532395, in order to close many "Me too only comments without sufficient data for problem analysis" as "dup of that bug". > Again, this particular thread is about sigs, > but I think that actual issue here is more generic to (snip) embeds, (snip) As you say, "(a) bug 817245, bug 453196 + (b) bugs listed in dependency tree for (a)", and majority in bug 532395, are "embed image specific". "embed image in HTML message body or embed image in Signature part" is absolutely irrelevant. However, "Signature case" may involve Signature specific different problem. Problem analysis of this bug is still incomplete, because sufficient data for problem analysis is not provided yet by any problem reporter in this bug. > but I think that actual issue here is more generic to IMAP4 (snip) Bug 817245 is applicable to local mail folder(local Drafts folder) only, although bug 453196 is applicable to both local mail folder and IMAP mail folder. What is "IMAP specifc part" in your problem(or in this bug)? If IMAP, MessageKey==UID of mail. So, MessageKey won't be altered by any one. If IMAP, a mail of specific UID can be deleted by any IMAP client if IMAP folder is shared. No access to your IMAP folder by other IMAP client including other TB instance. (In reply to bhendel from comment #29) > I just cancel the send delete the image in the attachment and it send fine. "Embed image" is used for "embed image in HTML via cid: URL"(i.e. image part in correctly structed multipart/related) in many cases. "Attached image file" case? (i.e. image part in multipart/mixed) Or "non referred/used image part in multipart/related or multipart/alternative"? (i.e. wrongly structed mail)
WADA, to clarify, about your last point, I select and delete the embedded image from the inline message, so no attachment here. Sorry for the confusing language. In case it is relevant, I am using MailEnable Pro 5.x. What can I do to help here? Any log files? Do you want me to try a stack trace? -Brian
(In reply to bhendel from comment #33) > What can I do to help here? First thing you has to do is; read already well known two bugs well, understand what occurs in these two bugs, and check "image URI of embed image in composing HTML mail" when you see your problem(see bug 817245 comment #0). > Image location of the image by Reply/Forward in inline(HTML mode). > imap://user-id@imap.gmail.com:993/fetch%3EUID%3E/INBOX%3Ennn?part=1.2&filename=EmbedImage.jpg > mailbox:.../Inbox%3Ennn?part=1.2&filename=EmbedImage.jpg Phenomenon and Cause of problem of these two bugs is prety simple. bug 453196 : Because "mail of specified MessegeKey which existed upon start of reply/forward/edit draft" is deleted, Tb can't find mail which contains the image data. bug 817245 : (local mail folder only) Because "MessegeKey==offset of replied/forwarded mail or previous draft mail" is altered by Compact, Tb can't find mail which contains the image data. In this case, if embed image in HTML mail, Tb shows "Attaching..." forever. Note: MessegaKey == "nnn" part after %3E in image URL if IMAP, UID of replied mail or previous version of draft mail if local folder, offset of replied mail or previous version of draft mail This MessageKey is shown as "Order Received" column value. What is "IMAP specific" part in your problem?
Something I would also like to mention at this point is I had another case of an embed in an attachment causing a "Attaching..." staff, however I waited a few seconds, cancelled, and then pressed sent again without removing, and the second time it worked. I am not familiar with the technicals of IMAP4, but this might suggest that it is not related to a deleted draft.
(In reply to bhendel from comment #35) > Something I would also like to mention at this point is I had another case of an embed in an attachment causing a "Attaching..." staff, > however I waited a few seconds, cancelled, and then pressed sent again without removing, > and the second time it worked. I am not familiar with the technicals of IMAP4, > but this might suggest that it is not related to a deleted draft. If same issue as bug 817245 or bug 453196, such phenomenon can not occur. "Second attempt after Cancel/without remove image" should produce "endless Ataching..." again, and "further attempt after Cancel/without remove image" should produce "endless Ataching...". It may be "temporary access failure" to mail of MessageKey==UID for replied/forwarded mail or previous draft in IMAP folder. "One of reasons why bug 532395 was kept open" is some "Me too" comnents on IMAP case which can't be explained by bug 817245 or bug 453196. If you see your problem next time, check "image URL of composing mail" and "mail of UID which is reffered by the image URL", please.
If I double-click the embed in the message that I am composing I get: imap://brian%server%2Ecom@mail.server.com:993/fetch%3EUID%3E/INBOX%3E37408?part=1.2&filename=image001.png So it looks like it is referencing UID: 37408. Every time I create a new email, the embed in my sig has this same ID. If I "save" the message and check the embed image, it has the same ID. I think that the message with this UID was the "basis" email that I used to construct my signature. I searched the _index.xml manifest file in my Inbox (MailEnable Pro 5.x) and I found the UID: <ELEMENT ID="0E5A8A367C6F4045AD7F58980B0B80AB.MAI" UID="37408"><ATTACHMENTS>0</ATTACHMENTS> <CATEGORIES></CATEGORIES> <CC></CC> <CLASS></CLASS> <FLAGSTATUS>\SEEN \ANSWERED</FLAGSTATUS> <FROM>"someuser" &lt;adam@domain.com&gt;</FROM> <IMPORTANCE>3</IMPORTANCE> <MESSAGEDATE>2014-02-20T15:16:52</MESSAGEDATE> <MODIFIEDDATE>1146387238</MODIFIEDDATE> <READ>1</READ> <RECEIVED>2014-02-20T15:17:37</RECEIVED> <SIZE>22616</SIZE> <STATE>0</STATE> <SUBJECT>Update February 19</SUBJECT> <TO>"'Brian Hendel'" &lt;brian@domain.com&gt;</TO> </ELEMENT> I opened up 0E5A8A367C6F4045AD7F58980B0B80AB.MAI and I see a regular looking multi-part email. (I can send the whole thing if necessary. Received: : from ([127.0.0.1]) with MailEnable ESMTP; Thu, 20 Feb 2014 10:17:37 -0500 From: "Adam Guay-Mosey" <adam@domain.com> To: "'Brian Hendel'" <brian@domain.com> Subject: Update February 19 Date: Thu, 20 Feb 2014 10:16:52 -0500 Message-ID: <000c01cf2e4e$c94f54e0$5bedfea0$@domain.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_000D_01CF2E24.E07BBDE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8uTfA5gr37/UpERWaABvdgDLMW8w== Content-Language: en-ca X-ME-Bayesian: 0.000000 Return-Path: <adam@domain.com> This is a multipart message in MIME format. ------=_NextPart_000_000D_01CF2E24.E07BBDE0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01CF2E24.E07BBDE0" ------=_NextPart_001_000E_01CF2E24.E07BBDE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ... Let me know if you need more. This email file has existed on this server and never deleted. It is in my Inbox, not drafts. -Brian
It sounds identical phenomenon to following with embeding local image file, with local draft folder. 1. copose HTML mail, embed local image file in HTML mail. image URL=file://... 2. Save as draft. image data is embed in multipart/related of draft mail(MessageKey=XXX). In composin mail, image URL refers to MessageKey=XXX. 3. Save as draft. image data is retrieved from mail of MessageKey=XXX. latest draft is MessageKey=YYYY. image data is embed in multipart/related of latest draft mail(YYY). Because new draft is saved, draft of MessageKey=XXX is deleted. In composin mail, image URL refers to MessageKey=YYY. 4. If local Drafts folder, Compact alters MessageKey==Offset==YYY of latest draft. So, if Compact is executed on Drafts, bug 817245 occurs upon next draft save or send. 5. However, in this case, "original embed image at step 1" == file://... which points existent local file, and Tb knows it because user requested the file://... at step 1. So, Tb uses this original file://... upon next draft save or mail send. Because file://... points existent local file draft save/mail send is successfull, as in step 2. This looks for user "Retry is successful". Do step by step image URI check and draft mail's UID check, please. If you need to show us mail data, save mail in .eml or paste mail data in text file, and attach the .eml or .txt file to this bug, instead of pasting long mail data to bug. please.
Got same bug. Ubuntu Utopic Unicorn, 14.10 alpha version, Thunderbird 31.0. Bug is similar to comment #27: Unable to reply to email with inaccessible signature. If before sending empty image placements is deleted, sending works without any hitch. See attached images: http://rom.lv/pub/thunderbird_attach_bug/missing_signature_images1.png http://rom.lv/pub/thunderbird_attach_bug/missing_signature_images2.png
Experiencing the same error in version 31.0 under Ubuntu Linux. Can easily reporduce by pasting in this image (highlighted image, clicked copy and pasted inline to new email causes same result. Also, can not save draft - hangs "Attaching") Note that this image is from the signature of a correspondant that is inline in the reply message. Here is the result of a "paste" of the same in this textarea: photo 0b0ef20e-f08a-4a9e-9ca9-2a987a0e95d1_zps0cfa7d33.jpg Here is what it looks like in view source of the original incoming message: <a moz-do-not-send="true" href="http://s55.photobucket.com/user/Rbaum01/media/0b0ef20e-f08a-4a9e-9ca9-2a987a0e95d1_zps0cfa7d33.jpg.html" target="_blank"><img src="cid:part21.02080600.07060603@[REDACTED].com" alt=" photo 0b0ef20e-f08a-4a9e-9ca9-2a987a0e95d1_zps0cfa7d33.jpg" border="0"></a> If anyone would like me to send them something please let me know what. I'd love to help solve this one - seems to plague a lot of people who don't realize what is causing it (at least I know how to delete the images to get it to send now)
I can confirm that, in my case, the problem was "caused" by an image part of the signature of the email sent to me. When I replied to it, it stayed "attach"ing forever. Deleting that image in my contact's signature, solved the problem, and my email followed its way. Ubuntu 14.04 Thunderbird 31.0
Hi, I´m Q.A and did some tests, and for finish this problem is necessary install the Thunderbird Setup 33.0b1.exe version. Now I did some test send image with many format and for many people and now is OK. This version fix this bug.
(In reply to Oscar Correia from comment #42) > Hi, I´m Q.A and did some tests, and for finish this problem is necessary > install the Thunderbird Setup 33.0b1.exe version. > > Now I did some test send image with many format and for many people and now > is OK. This version fix this bug. Installed 33.0b1 and so far so good. Seems fixed.
I can confirm that I'm getting the same problem as David above - the problem was "caused" by an image part of the signature of the email sent to me. When I replied to it, it stayed "attach"ing forever. Deleting that image in the signature of the email sent to me, solved the problem, and the email went out properly. OSX 10.8.5 Thunderbird 31.3.0
Can confirm I'm having the same issue with 31.4.0 If I try and reply to an email that has an image embedded in it, usually the signature then it hangs stating attaching.. Does not happen when attaching / embedding images into my reply.. Only the signatures etc that are transferred from the email I'm replying to.
External symptom/phenomenon of problem is clearly stated in bug summary of Bug 532395. Closing as DUP of Bug 532395 to avoid useless "Me too" comments to this bug. If duping is wrong, plese re-open this bug with attching sufficient data for problem analysis.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.