Open Bug 501298 Opened 15 years ago Updated 2 years ago

TB fails to send/attach inline images of type <img src=URL1> if URL1 is redirected to URL2; looks good when composing, but fails silently and sends broken message without warning (only save as draft will warn)

Categories

(Thunderbird :: Message Compose Window, defect)

Product:
Thunderbird
Component:
Message Compose Window
Platform:
Other
Windows XP
Type:
defect

Tracking

(Not tracked)

People

(Reporter: cherold, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Whiteboard: [STR comment 17][re-evaluate duplicates after fixing]) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11
Build Identifier: version 2.0.0.21 (20090302)

I just hit this error. This is what occurred.  First I selected a web page with a lot of images, copied it and pasted it into an email.  Then I edited out the parts of web page that I didn't want.  Since I wasn't sure if the images would go through, I sent a test email to my gmail account.  This worked fine.

I then went into my sent email and chose that same email.  I added a little text at the top, put in a bunch of my friend's email addresses, hit send and got a message, "Sending of message failed. There was an error attaching. Please check if you have access to this file."

Googling around I found a forum where a number of people have the same error, but I couldn't find this bug listed here, although it may be here somewhere.

Reproducible: Didn't try

Steps to Reproduce:
1. Go to http://www.impactlab.com/2009/03/20/crazy-photos-from-international-disturbed-peoples-day-email/ and do copy all then paste into a new message. (I assume this will work with any image/text combo, but this is the one I used).
2. Send it to someone.
3. Go to your sent mail folder, right click on the email and click "edit as new"
4. Add a line of text (may not be necessary, but this is what I did).
5. Put in some email addresses (I did them all as BCC).
6. Click "send."
Actual Results:  
"Sending of message failed. There was an error attaching. Please check if you have access to this file."

Expected Results:  
Obviously, the email should have gone out.  

Bug 461785 mentions a different error message relating to saving a message as draft that also says "error attaching," so it may be related.  But since it does not mention the issue of of sending, and since it appears to be related to IMAP, whereas I'm using a POP account, I don't know if it's connected.
BTW, my workaround for this was to simply delete the content of the email, go back to the webpage and select, past and edit it again, and then send it.  Since that worked, the problem would seem to be connected with "edit as new," or perhaps with the way Thunderbird saves sent email with images.
I can confirm this same behavior in Thunderbird 2.0.0.23.  When hitting REPLY to a message with an attached picture, the error message appears.  When hitting FORWARD instead, it works fine.
Anything in Tools -> Error console when this happens ?
Please mark as confirmed.

I have experienced this same error for years.  I was using v2 last week and it happened. I updated to v 3.0.3 and it is still happening.

I compose an email, with images. On first send it works fine. Then i select edit as new and try to send to others and get this error:

"Sending of message failed.
There was an error attaching . Please check if you have access to the file."

I get a similar error at the auto-draft save time and on manual save.  Each 5 minutes the error message pops up saying:

"Unable to save your message as draft.
There was an error attaching . Please check if you have access to the file."

I just tried a manual save and it produced the above error message so I cut and pasted it.

One time, for some reason none of my images (embedded within the body, not sent as attachments) got sent, except one.  The draft just showed the outline border of the image size and the received email just had the alternate text. When I re-applied the image links to all of them, all of the images then displayed on my draft but it wouldn't send.  Then I deleted the one image that had been sent on first mailing and re-added it.  I was then able to send.

hope these details help tracking it down because this is most frustrating.  I've only had a couple months of "C" so far so can't help with the code.
Additional thoughts on this.

I think it deserves to be escalated to major bug.

One of the big problems I have experienced relates to re-opening an email with 'edit as new' and them make significant changes.  This bug prevents sending it or saving the draft with changes. The only way to close the edit window is to X out then click [don't save], so all edits are lost.
A note:  I found one error entry in the console but it isn't timestamped, so all I can say is it was logged within the last week as this was the email I recently had problems with and prompted my report here:

Security Error: Content at about:blank may not load or link to file:///C:/Documents%20and%20Settings/User/My%20Documents/!%20%20%20%20nDn/!%20C___%20E___/!%20M___/Corrected%20-%20C___...html.

Just detected some things that may help:

These seem to be the conditions needed to replicate the error:
1] A previously sent email that contains inline images
2] Re-open such email with 'edit [message] as new'
     - all images are displayed
3] Save it [the 1st save seems to work]
     - all images still are displayed
4] Save it again, without making any changes and it refuses with error:
     
"Unable to save your message as draft.
There was an error attaching . Please check if you have access to the file."

Note:     - all images are still displayed in the draft

5] Save it again produces the same error, but now the images have disappeared. All that is displayed are the image shape outlines with the alternate text.
 
I tried to save as a template and got this error:

"Unable to save your message as template.
There was an error attaching . Please check if you have access to the file."

It DOES save as a file, in html. but... all the images are gone, in both the email draft and the html file. The email is only showing the border outline for their positions.

I tested more...and discovered that:
1] when reopened, all images are displayed in the email.
2] After the 1st save they are still displayed.
 After the second or third save attempt, the images in the draft disappear.

One time, testing with an email with multiple images, a security error for each was logged, such as this one:

Security Error: Content at mailbox:///C|/Documents%20and%20Settings/User/Application%20Data/Thunderbird/Profiles/e_______.default/Mail/pop3.mail.______.com/Sent?number=_______ may not load or link to file:///C:/Documents%20and%20Settings/User/My%20Documents/%21%20%20%20%20___/%21%20C______%20E___________/M_______/pic1234567890.jpg.

I kept testing, producing the same type of error over and over, but nothing was logged. Why it logged one failure and not the others is beside me, except that the path shown in the error above no longer exists. After I drafted the first email, I changed the subdirectory names from .../M_______/pic1234567890.jpg. to .../!%20M_______/pic1234567890.jpg. { added "! " in front of the old folder name so it would sort to the top]

But after I edited the email, I changed all the image links to point to the new .../!%20M_______/... folder.  But after a save, thunderbird changed it back to the now non-existent folder name without the "! " prefix.

After seeing that, I decided to test another email without an interim folder name change. I created an email with a single image. sent it. reopened with 'edit as new'. saved it immediately without any edits at all.

before, added this image:
file:///C:/Documents%20and%20Settings/Luser/My%20Documents/!%20My%20Pictures/!%20%20%20Webbers/Rocky%20Mountain%20High%20-%20504%20w712x534.jpg

after, thunderbird references this image location:
mailbox:///C|/Documents%20and%20Settings/Luser/Application%20Data/Thunderbird/Profiles/e______q.default/Mail/pop3.mail.________.com/Sent?number=#########&part=1.1.2&filename=Rocky%20Mountain%20High%20-%20504%20w712x534.jpg

The email with image sent normally.
On reopening with 'edit as new', the image was displayed.

the image location was:
mailbox:///C|/Documents%20and%20Settings/Luser/Application%20Data/Thunderbird/Profiles/e______q.default/Mail/pop3.mail._______.com/Sent?number=6016658&part=1.1.2&filename=Rocky%20Mountain%20High%20-%20504%20w712x534.jpg

I clicked [save] and it worked, however I noticed the 'Sent?number=' info changed!.

mailbox:///C|/Documents%20and%20Settings/Luser/Application%20Data/Thunderbird/Profiles/e______q.default/Mail/pop3.mail._______.com/Sent?number=3203200&part=1.1.2&filename=Rocky%20Mountain%20High%20-%20504%20w712x534.jpg

I clicked save again and got the infamous error:
"Unable to save your message as draft.
There was an error attaching . Please check if you have access to the file."

I am suspecting thunderbird is reverting to stale data, changing the image pathname to one no longer existing.
Can you share an email that exhibits the issue ?
Using Windows XP SP3
Thunderbird 3.0.4
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4

My scenario is trivial:

The first 3 or 4 steps are not really relevant:

1. Receive an email with another email message attached.
2. Detach the attached message.
3. Open the detached message in Thunderbird.  Message is HTML.
4. Edit as New, and Send.
5. Get "Error attaching files" message.
6. Delete images, i.e. links, for which there is no target file.
7. Send OK.

In my scenario, broken links don't matter.  I.e., I can send the message as is, with links to non-existent files.  

I'd like the option of sending the message as is.

Regards, Bob
Hi, 
Why is the status of this BUG still "UNCONFIRMED"?
It is so easy to replicate, and a debilitating, time consuming BUG. 
I experience this repeatably with TBird for Mac when trying to save an email created by the "Edit as new message" function that has an embedded image.

Please change status to CONFIRMED and, may I humbly request that someone have a go at fixing it!
we have a few dupes to this, but I'd be surprised if there isn't an older, possibly confirmed, bug report on this.
Whiteboard: [dupeme?]
This has been confirmed, is easily reproducible. All it needs is for some talented programmer to review the details above to see what is happening. 

It appears to me TB creates a temporary location where is caches the image. Once the image is sent, the cached image is deleted. But when opened to "edit as new" it looks for the now empty cache location and not the original location of the image file where it remains available. (documented above)
(In reply to Wayne Mery (:wsmwk) from comment #12)
> we have a few dupes to this, but I'd be surprised if there isn't an older,
> possibly confirmed, bug report on this.

Absolutely - please mark this bug as CONFIRMED! I reported bug 593741 which David Bienvenu acknowledged as a problem. He was previously one of Mozilla's full time developers.
Are you guys using current builds.
Most of these problems should have been fixed by bug 380372 and bug 692875
Which means TB10 and above should work fine.
agreed. this seems to be a duplicate of some issues raised and fixed recently in 380372 from 2007. I am currently using TB 12.0.1 and it appears to be fixed now. Thanks much.
(In reply to BugMagnet from comment #16)
> agreed. this seems to be a duplicate of some issues raised and fixed
> recently in 380372 from 2007. I am currently using TB 12.0.1 and it appears
> to be fixed now. Thanks much.

Unfortunately not. Following steps from comment 0 exactly as still fails. But the reason for this bug is entirely surprising. Here's how, and why:

Short version:

The testcase of comment 0 fails:
<img src=URL1> in message body fails
because URL1 on the website is redirected to URL2 (which is true location of img). The problem is that Insert Image dialogue or Copy and Paste does not show any visible problems, problems only occur when saving as draft.

<img src=URL2> in message body succeeds.


Long version:

(I'm using POP3 acct on TB 12.0.1 on WinXP)

STR

1 open this URL from comment 0 in browser:
http://www.impactlab.net/2009/03/20/crazy-photos-from-international-disturbed-peoples-day-email/

2 from context menu of apple-butterfly image, "Copy Image"

3a Create a new message with subject "Image1 from redirected location", and in body of composition, right-click, Paste
3b double-click on pasted image and note Image Location URL (img src)
3c Save Draft (Ctrl+S)

4a go back to browser, from context menu of apple-butterfly image, "Copy Image Location"
4b Paste img url into browser's location bar, and watch location bar closely as you press Enter to load the image

5 from context menu of img of 4b (image-only-view in browser), "Copy Image"

6a create a new Message with subject "Image2 from real location", right-click, Paste
6b double-click pasted image (from step 6a), and note "Image Location" URL (img src)
6c Save draft

7 compare img URLs noted in 3b vs. 6b

Actual results

Img1, referenced as URL1 (which is redirected to URL2):
3a: copy of original img1 copied directly from containing site looks fine
3b: URL1: img1 location (src) =
http://www.impactlab.com/wp-content/uploads/2009/03/apple.JPG
(Note: site = impactlab.*com*
3c: Save as draft with inline img1 (src=URL1) fails, because URL1 is not the real URL of this picture, it is redirected to URL2

4a on the website, img1 is embedded as <img src=URL1> (impactlab.com)
4b location bar redirects image URL from URL1 to URL2 (impactlab.net):
   http://www.impactlab.com/wp-content/uploads/2009/03/apple.JPG
-> http://www.impactlab.net/wp-content/uploads/2009/03/apple.JPG

6a copy of img2 (this time copied from true location) looks fine
3b: URL2: img2 location (src) =
http://www.impactlab.net/wp-content/uploads/2009/03/apple.JPG
(Note: site = impactlab.*net*
3c: saving draft with inline img2 (src=URL2) succeeds, because this is the real (non-redirected) URL of this image. Re-opening, sending etc. also succeeds, except cases of bug Bug 754655.

Now we need to check for duplicates if this problem is already reported.
Suprisingly during my tests:

- for redirected img src, always get this 1st error:
"There was a problem including apple.jpg in the message. Would you like to continue saving the message without this file?"
- but only sometimes got 2nd error (can't verify the wording):
"Sending of message failed. There was an error attaching. Please check if you have access to this file."

In most cases, in spite of failing to attach the img, TB just proceeds and sends msg without image without any notice. Iow, if autosave or manual save doesn't happen before sending, you'll send broken message without knowing. Grrr!
Whiteboard: [dupeme?] → [dupeme?][STR comment 17]
Summary: "error attaching" message for emails started as "edit as new" → TB fails to handle inline images of type <img src=URL1> if URL1 is redirected to URL2; looks good when composing, but fails silently and sends broken message without warning (only save as draft will warn)
David B., any ideas why Insert-Image-preview and composition look all fine, but when saving and embedding the redirected image, we fail?
It's quite possible that the content policy doesn't allow redirects on our http urls when fetching images. I don't know much about how http redirects work internally in necko, or what we have to do to get redirects to work, and even if it's a good idea to do so.
At first glance, cannot find dupes about problem of "redirected inline images".
-> Confirming.

Bug about problems with inline images when "Edit as new" is Bug 599843.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [dupeme?][STR comment 17] → [STR comment 17]
(In reply to David :Bienvenu from comment #20)
> It's quite possible that the content policy doesn't allow redirects on our
> http urls when fetching images. I don't know much about how http redirects
> work internally in necko, or what we have to do to get redirects to work,
> and even if it's a good idea to do so.

Well, if there was a content policy of not allowing redirects when fetching images, why are we showing the same redirected image nicely in preview of "Insert > Image" Dialogue, as well as in editor?

Iow, image redirects seem to be allowed and working, and it's only the embedding part which breaks.
(In reply to Thomas D. from comment #22)
I would have thought that my post made it extremely clear that I do not know. I will attempt to find out.
> 
> Well, if there was a content policy of not allowing redirects when fetching
> images, why are we showing the same redirected image nicely in preview of
> "Insert > Image" Dialogue, as well as in editor?
>
Confirming this bug on Seamonkey nightly.
STR:
- Create a new message (composition in HTML)
- include an image
- CTRL + S (Save as draft)works once
- Unable to save a second time

If "automatically save the message every X minutes" is on, you only have the message saved at the first cycle.

Setup: Seamonkey nightly (using Thunderbird composition and mail), IMAP account.
Same problem also occurs for attached web pages if they are redirected, per bug 529255.
See Also: → 529255
See Also: → 215665
Summary: TB fails to handle inline images of type <img src=URL1> if URL1 is redirected to URL2; looks good when composing, but fails silently and sends broken message without warning (only save as draft will warn) → TB fails to send/attach inline images of type <img src=URL1> if URL1 is redirected to URL2; looks good when composing, but fails silently and sends broken message without warning (only save as draft will warn)
Depends on: 204250
Neil, aceman, anyone, can you provide a starting point in code where upon saving/sending of composition, we traverse <img...> tags and get the actual image data for saving as inline mime parts?
That's where we fail when the img src is redirected to another URL.
It's about time we start acting on the large cesspool of failures around inline images:

https://bugzilla.mozilla.org/buglist.cgi?quicksearch=%3Athun%2Cmailn%20inline%20image%2Cpic%2Cgraphic&list_id=11467395
Flags: needinfo?(neil)
Flags: needinfo?(acelists)
Whiteboard: [STR comment 17] → [STR comment 17][re-evaluate duplicates after fixing]
No, I do not touch that ugly code :) But I think jcranmer is working in that area.
Flags: needinfo?(acelists)
Joshua, as a mime specialist, can you comment wrt code starting point?

(In reply to :aceman from comment #29)
> No, I do not touch that ugly code :) But I think jcranmer is working in that
> area.

(In reply to Thomas D. from comment #28)
> Neil, aceman, anyone, can you provide a starting point in code where upon
> saving/sending of composition, we traverse <img...> tags and get the actual
> image data for saving as inline mime parts?
> That's where we fail when the img src is redirected to another URL.
> It's about time we start acting on the large cesspool of failures around
> inline images:
> 
> https://bugzilla.mozilla.org/buglist.
> cgi?quicksearch=%3Athun%2Cmailn%20inline%20image%2Cpic%2Cgraphic&list_id=1146
> 7395
Flags: needinfo?(Pidgeot18)
Following STR of comment 17, I am failing earlier at step 3c. Error is NS_BINDING_REDIRECTED  Stack is:

 	xul.dll!nsMsgAttachmentHandler::UrlExit(tag_nsresult status, const wchar_t * aMsg) Line 1058	C++
 	xul.dll!FetcherURLDoneCallback(tag_nsresult aStatus, const nsACString_internal & aContentType, const nsACString_internal & aCharset, int totalSize, const wchar_t * aMsg, void * tagData) Line 467	C++
 	xul.dll!nsURLFetcher::OnStopRequest(nsIRequest * request, nsISupports * ctxt, tag_nsresult aStatus) Line 279	C++
 	xul.dll!nsURLFetcher::OnStateChange(nsIWebProgress * aProgress, nsIRequest * aRequest, unsigned int aStateFlags, tag_nsresult aStatus) Line 369	C++
 	xul.dll!nsDocLoader::DoFireOnStateChange(nsIWebProgress * const aProgress, nsIRequest * const aRequest, int & aStateFlags, const tag_nsresult aStatus) Line 1331	C++
 	xul.dll!nsDocLoader::FireOnStateChange(nsIWebProgress * aProgress, nsIRequest * aRequest, int aStateFlags, tag_nsresult aStatus) Line 1268	C++
 	xul.dll!nsDocLoader::doStopURLLoad(nsIRequest * request, tag_nsresult aStatus) Line 828	C++
 	xul.dll!nsDocLoader::OnStopRequest(nsIRequest * aRequest, nsISupports * aCtxt, tag_nsresult aStatus) Line 630	C++
 	xul.dll!nsLoadGroup::RemoveRequest(nsIRequest * request, nsISupports * ctxt, tag_nsresult aStatus) Line 689	C++
 	xul.dll!mozilla::net::nsHttpChannel::ContinueHandleAsyncRedirect(tag_nsresult rv) Line 512	C++
>	xul.dll!mozilla::net::nsHttpChannel::OnRedirectVerifyCallback(tag_nsresult result) Line 5939	C++
 	xul.dll!nsAsyncVerifyRedirectCallbackEvent::Run() Line 52	C++

nsMsgAttachmentHandler is probably the code that you should be looking at.
(In reply to Kent James (:rkent) from comment #31)

Thanks Kent for providing the stack!

> Following STR of comment 17, I am failing earlier at step 3c.

Yes, it fails at 3c as I described in Actual Results of comment 17. The remaining steps are just comparison with the non-redirected case which works.

> nsMsgAttachmentHandler is probably the code that you should be looking at.

Can somebody narrow this down further?

http://mxr.mozilla.org/comm-central/search?string=nsMsgAttachmentHandler
(In reply to Thomas D. from comment #28)
> Neil, aceman, anyone, can you provide a starting point in code where upon
> saving/sending of composition, we traverse <img...> tags and get the actual
> image data for saving as inline mime parts?

The magic all starts in nsMsgAttachmentHandler::SnarfAttachment--this takes the URL we parsed from the src="" handler of the image attachment, creates an nsURLFetcher to grab the content, and waits for it to be downloaded. nsURLFetcher kicks of an nsIURILoader to open the URI and get the data--see nsURLFetcher::FireURLRequest.

If there's redirection failure going on, likely it's the nsURLFetcher code that needs fixing. I don't know how HTTP redirects happen, but the code who likely needs to be modified is the nsURLFetcher. Reading a bit of HTTP code, it seems you can probably get the redirects handled via <http://dxr.mozilla.org/comm-central/source/mozilla/netwerk/base/public/nsIChannelEventSink.idl>--set up a channel event sink, unconditionally accept the redirect when asked for, and then hopefully everything would work.
Flags: needinfo?(neil)
Flags: needinfo?(Pidgeot18)
We're getting more complaints on Bug 532395 again, which is the collect-all bug for failing inline images. I firmly believe we have to start somewhere to dry out this cesspool. I we are lucky, this might fix a lot of the cases reported. This looks like a good start because the cause is clearly confined and comment 31 and comment 33 provide an informed and detailed starting point in code.

Who could try to fix this? Joshua seems to have an excellent understanding of the code ;)
Flags: needinfo?(Pidgeot18)
(In reply to Thomas D. from comment #34)
> We're getting more complaints on Bug 532395 again, which is the collect-all
> bug for failing inline images. I firmly believe we have to start somewhere
> to dry out this cesspool. I we are lucky, this might fix a lot of the cases
> reported. This looks like a good start because the cause is clearly confined
> and comment 31 and comment 33 provide an informed and detailed starting
> point in code.
> 
> Who could try to fix this? Joshua seems to have an excellent understanding
> of the code ;)

I'm working on a complete replacement of the entire infrastructure from nsMsgSend.cpp down, which includes nsUrlFetcher. The replacement will be based on XMLHttpRequest (or maybe Fetch), which would hopefully fix this issue, if it is a failure in nsUrlFetcher.
Flags: needinfo?(Pidgeot18)
Hi Joshua,

I'm *really* glad to hear this!

I hate to ask, but... do you have even a guess at how long it might be before such a fix might arrive? Obviously I doubt it would be for the next major release (38), but maybe for the next one (45?)?

Thanks!!!
I'm aiming for later this year--I'll probably start posting patches for interface reorganization in late March or early April, and the entire queue should be ready to land hopefully mid-late summer.
(In reply to Joshua Cranmer [:jcranmer] from comment #37)
> I'm aiming for later this year--I'll probably start posting patches for
> interface reorganization in late March or early April, and the entire queue
> should be ready to land hopefully mid-late summer.

Thanks Joshua, that's great news. Looking at...
- the very high number of users affected by embedded image failures (87 votes, 12 duplicates on Bug 532395), and more on other bugs
- the very limited scope of this bug 501298, and
- your concise knowledge of the code here (as documented in comment 33 quoted below)
...I would think it would be worth it for you to try and fix this particular bug 501298 without waiting for the entire infrastructure replacement to land?

(In reply to Joshua Cranmer [:jcranmer] from comment #33)

> The magic all starts in nsMsgAttachmentHandler::SnarfAttachment--this takes
> the URL we parsed from the src="" handler of the image attachment, creates
> an nsURLFetcher to grab the content, and waits for it to be downloaded.
> nsURLFetcher kicks of an nsIURILoader to open the URI and get the data--see
> nsURLFetcher::FireURLRequest.
> 
> If there's redirection failure going on, likely it's the nsURLFetcher code
> that needs fixing. I don't know how HTTP redirects happen, but the code who
> likely needs to be modified is the nsURLFetcher. Reading a bit of HTTP code,
> it seems you can probably get the redirects handled via
> <http://dxr.mozilla.org/comm-central/source/mozilla/netwerk/base/public/
> nsIChannelEventSink.idl>--set up a channel event sink, unconditionally
> accept the redirect when asked for, and then hopefully everything would work.
:jcranmer
^^ comment 38
Flags: needinfo?(Pidgeot18)
See Also: → 560210
(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #38)
> ...I would think it would be worth it for you to try and fix this particular
> bug 501298 without waiting for the entire infrastructure replacement to land?

Honestly, as you might have guessed, I have had rather less time over the past year and likely for the next year or so than I thought I would. I'd rather spend that precious little time trying to get the replacement infrastructure landed rather than try to coddle horribly broken subsections of the current compose backend.
Flags: needinfo?(Pidgeot18)
Another comment on this behaviour buggy comportment that has not been corrected for more than 10 years (copy pasted images lost when long time spend on mail writing before sending) :

The image i pasted in some of same circonstances has been replaced by ANOTHER one !
Hopefully, saw this because i send that mail to a list in which i was a member.

This was not an error on my part, i'm sure of my this enormous bug happened.
(The image was one i copied pasted one week before... Used Screenpresso as a copy/paste tool...)
I have been using Thunderbird on both Windows and Mac platforms for at least 10 years.  Just today I encountered this particular bug.  It drove me nuts trying to figure out the source of the problem.  I had been attaching 2 screenshots for troubleshooting an ecommerce site I am working on.  It would just sit and spin "
attaching graphics1..." forever.  

I deleted my signatures that call image files from my websites.  
No change.
I deleted the inline images.
No change.
I added the images as attachments.
No change
I uploaded the screenshots to my website and put in links to them.
No change.
I upgraded Thunderbird from version 38 to 45.1.
You guessed it - No change.
I rebooted the computer (a beast of a Mac Pro that takes about 10 minutes to restart.
No change.

It was still trying to load some infernal graphic from someplace that was not responding.

Wait...
Just...
A...
Danged...
Minit...

Embedded in the message I was sending was a quote I had pasted in from a previous email about a year ago.  Embedded in that quote was the signature file of the person who sent it to me, who apparently is no longer there.  I did not notice the tiny box where a signature graphic used to be.  That infernal signature file was trying valiantly to load an image from a non-existent account.  I deleted the link to the image and everything worked as before.

That's my story for today.  If it helps anyone out, that's great.
I had my own version of this bug today:

We have recently migrated our website from HTTP to HTTPS as more and more companies do.

The logo img in our signature is used from that webserver and we failed to change the signature to use HTTPS. But our webserver does redirect HTTP URLs correctly to the corresponding HTTPS URLs. 

Now TB loads the image nicely when composing an email (redirect works) but fails when sending it with an error that embedding the image is impossible. Changing the signature to use the HTTPS URL of the image solved the problem.

I guess this scenario will happen more often in the future as more companies change their websites to HTTPS and implement redirects.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.