404922 - compose window fails to recognize updated image file when using drag and drop

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect)

Description

[David Cumberbeach]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
Build Identifier: 1.5.0.14pre (20071121)

When dragging and dropping an image from a file window to the mail compose window, the compose window will embed a previous version of an image which has been updated since it was last dropped into the mail compose window, during the current Thunderbird session.

Reproducible: Always

Steps to Reproduce:
1. Drag and drop an image from a file window to a mail compose window to create an inline image
2. Open original image file and make a change (eg. change colour). Save (same file name & location)
3. Delete the inline image from the mail compose window
4. Drag and drop the new image from the file window to the compose window again.
Actual Results:  
Previous version of the image appears as an inline image

Expected Results:  
Updated version of the image should appear as an inline image

Workaround: Deleting the old image, saving a draft of the message and then restarting Thunderbird before dragging and dropping the updated image will result in the correct behaviour.
Reproducible with both gif and jpg images.
"Insert > image..." from menu results in correct behaviour.

Comment 2

[rsx11m]

The general issue appears to be that - at the time of inserting the image - only a "file://" reference is added into the message body. When sending or saving as draft, the image is encoded and "file://" replaced by a "cid:" reference. Thus, any change of the file containing the attachment results in the described ambiguity which version to display. In either case, the content of the file present at the time of sending should be taken regardless of what is displayed (which is the case in the scenario outlined by bug 461774, which is not an exact duplicate but should be covered by the same mechanism).

Whether this can be considered a bug or behavior by design is not quite clear. The only other option would be to copy the current contents of the file into some temporary location (as is done with images from the clipboard, for example) and to ensure in this way that the contents is not lost if the file is overwritten or removed from its original location.

Comment 3

[rsx11m]

This is still reproducible as described with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081027 Shredder/3.0b1pre. The old contents of the file shows up when deleting the inserted image, change the original, then reinserting the new file with the same name. The old image appears until the message is sent, it is updated by the actual contents while sending.

A variant of this may be bug 383336, where the contents of the previous file is even preserved through closing and reopening the composition window. Note the dependency of that bug to bug 450738 on image caching from local files.

Interestingly, bug 461774 now behaves differently on trunk. If not deleting the first image, it will stay displayed correctly when the second image from the same file is dropped into the message. The second image renders correctly though, in contrast to the other two scenarios. When sent, as soon as sending starts, the first image changes to the content of the second image, and this is also how the actual message is displayed when received (having the image attached just once but referred to twice in the HTML part).

Comment 4

[rsx11m]

I had another look at Editor bug 437217, which describes a similar issue when pasting MS-Word drawings into either the mail/news-composition or the composer window. Interestingly, it turns out that MS-Word is reusing its own temporary file "clip_image001.gif" and a reference to it is pasted into the HTML code. Thus, the update of that file is not reflected in the image shown in the composition either. I also see bug 461774 in this scenario, sending the last pasted image twice, but interestingly, the first preview image is not updated for pasting from MS-Word, whereas it was updated correctly in PNG pasting from MS-Paint, as described in the last paragraph of my previous comment.

So, while this is somewhat inconsistent in terms of reproducibility for the multiple image in the same composition case, it appears that all of these bugs here relate to the same bug in the Editor Core component.

Comment 5

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #2)
> The general issue appears to be that -
> at the time of inserting the image - only a "file://" reference is added into the message body.
> When sending or saving as draft, the image is encoded and "file://" replaced by a "cid:" reference.
> Thus, any change of the file containing the attachment results in the described ambiguity which version to display.

To [e-mail]:
I think so too.
Bug 378046 is similar user's complaints of "confusing Tb's behaviour on file attachment" due to current mechanism.

Comment 6

[rsx11m]

Yes, this appears to be all related to that single issue (apart from the caching of a wrong preview image, but even that would be resolved if the reference = real image would not be the same file). The most general solution appears to be hidden in bug 447585, resolved as a dupe of bug 378046, essentially suggesting to copy any attachment (and embedded image for that matter) to a temporary location, to ensure that a "snapshot" of that content exists regardless of what happens to the original. This would put attachments on the same level as images from clipboards, which are currently handled that way. I see the performance issue though that having to first copying a 10MB attachment may raise, and appropriate cleanup would have to be taken care of, thus it's a trade-off (as always).

Comment 9

[rsx11m]

I'm confirming this as it is still reproducible in current trunk builds
(tested on Windows nightly) and the developments in bug 378046 towards a
general snapshot solution to ensure attachment consistency have stalled.

Comment 11

[(no longer active)]

Is there something about this which needs to be done on the editor side?

Comment 12

[rsx11m]

I don't think so, thanks for stopping by. I have just tested the original scenario (drag-and-drop of a PNG file from disk, then modifying it, drag it again into the same message) and the first image reflects the original whereas the second image the updated contents of the file. So this works fine now for the Miramar TB3.3a1 build on Windows 7 with your patch from bug 609632.

Unless someone else finds this unfixed, I'd suggest to close as "works for me". There have been a couple of duplicates, but they intuitively seem all covered.

Comment 13

[(no longer active)]

On a closer look, this should be fixed by bug 609632, because now we will always look at the raw file data, and we don't rely on the contents of a file:/// URI being cached.