458899 - When you copy-paste material to email, if there's an image, but TB can't find the link, it searches forever

Status: UNCONFIRMED

(MailNews Core :: Composition, defect)

Description

[michael]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Dealio Toolbar 3.1 Firefox/3.0.3
Build Identifier: Thunderbird version 2.0.0.17 (20080914)

When you copy-paste material to email, if there's an image, but TB can't find the link, it searches forever. When trying to send a message with a link to an image that it can't find, it says, "

Reproducible: Always

Steps to Reproduce:
1. Copy-Paste some text with an image -- say that you receive from another email -- into the "Message" section.
2. Hit Send
3. "Status: attaching"
Actual Results:  
The "Status: Attaching" message just stays there with the green Progress bar running.

Expected Results:  
The mail would be sent or it would TIME OUT.

happens on XP. Also, we've tried sending a few similar emails. Some actually produce "Failure" messages. Emails with only, say, one attachment, seem not to trigger the Failure message though.

Comment 1

[rsx11m]

Similar effects have been reported in bug 468159 when forwarding messages with embedded images and in bug 418203 with images in signatures. According to the latter, the issue appears to be resolved in current Thunderbird 3.0 builds.

What does "can't find the link" mean? Is it invalid at the time of sending?

If you don't want to to try 3.0 beta 2, let's keep this open until 3.0 is released. If it's no longer reproducible then, this report should be closed.

Comment 2

[michael]

You said: "What does 'can't find the link' mean? Is it invalid at the time of sending?"

My reply: Correct; if the link is invalid, TB just keeps searching forever for the non-existent link.

Comment 3

[rsx11m]

Thanks. So, this case is similar - but not identical - to bug 453196 then.

Comment 4

[rsx11m]

I've done some further testing and got various clues [Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090326 Shredder/3.0b3pre].

First, I've tried copy-pasting from a web site with an image, which actually inserts an "http:" link and resolves it when sending (thus, connecting to the server when inserting and - if not cached - again for encoding). Removing the image from the web site does have no effect when the image is cached, it is nevertheless encoded and sent. If the server has to be consulted again, it still creates successfully an attachment to the message, however using the HTML error message from the server along with the "image/*" MIME type (this doesn't look quite right either).

> Copy-Paste some text with an image -- say that you receive from another
> email -- into the "Message" section.

If the source e-mail is removed after pasting the image, it corresponds to the behavior described in bug 453196. It doesn't seem to make any difference if the image got into the message by copy-pasting or by replying. I will add those observations regarding stalling vs. error message there, it depends on whether or not the message was deleted and then the folder compacted afterwards.

Do you have further test cases regarding copy-pasting from a web site and then removing the source before it is completely attached? If yes, and if no report is pending on that already, we could make this the focus of your bug report. Reattaching inline images from other e-mails is covered in bug 453196.

Comment 5

[michael]

To be exact, I wasn't copy/pasting the link from a web page, but from my hard drive. I doubt if that makes much difference, but I thought I'd mention it in case it does.

Comment 6

[rsx11m]

Well, I created an HTML page on my hard drive with a local image file included, copy-pasting into the composition window showed the image, then I changed the path. The message went out, but without the image. Instead, it had the "file:" URL to my local drive included. So that's in a similar category as bug 391190.

Comment 7

[rsx11m]

I've initially tested on both Windows and Linux, and while copy-paste from mail boxes or HTML pages or using replies works fine on Linux, for copy-pasting from message to message you should also see bug 417204 breaking the encoding of the drive letter on Windows. This case prompts an error message, but not stalling.

Since I could reproduce the issue on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090326 SeaMonkey/2.0b1pre as well, I'm changing this to MailNews Core.

Comment 8

[Thomas D. (:thomas8)]

Fwiw, anything which is inserted into composition and will not remain a remote link upon sending, should be immediately physically inserted into composition at the time of user's inserting, not when sending. When I copy an online image as an image into my composition, that very image should be physically copied into my composition immediately as-is, regardless of whether that image has been changed or deleted on the remote server at the time of sending or not. We need to observe wysiwyg, and avoid dataloss.

Same underlying problem as seen in bug 378046 for attaching files.

Comment 9

[Thomas D. (:thomas8)]

Looking at bugs like bug 378046, bug 391190, and this bug 458899, this seems a general and very pervasive problem. I wonder if we need a meta bug to track all those bugs where we lose content because we add some temporary links to stuff instead of adding the stuff itself immediately, and then when we actually try to get the stuff when sending (i.e. at an unpredictable later time), it might be altered, moved, or deleted, hence causing dataloss and compromising privacy (as I can never be 100% sure if what I inserted is what will actually get sent).

Comment 10

[Wayne Mery (:wsmwk)]

(In reply to Thomas D. (currently busy elsewhere) from comment #9)
> Looking at bugs like bug 378046, bug 391190, and this bug 458899, this seems
> a general and very pervasive problem. I wonder if we need a meta bug to
> track all those bugs where we lose content because we add some temporary
> links to stuff instead of adding the stuff itself immediately, and then when
> we actually try to get the stuff when sending (i.e. at an unpredictable
> later time), it might be altered, moved, or deleted, hence causing dataloss
> and compromising privacy (as I can never be 100% sure if what I inserted is
> what will actually get sent).

Does this still occur with version 60?