461774 - if i grab/drop desktop file, later update file then next grab/drop uses old file, not new one

Status: RESOLVED DUPLICATE of bug 404922

(Thunderbird :: Message Compose Window, defect)

Description

[Joe Grames]

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

Rather that use Insert/Image I often grab/drop image from desktop into composer. This works successfully, however, I have noticed that if I update the image on my desktop, however, keep the same file name, when I next grab/drop that file to the composer it uses the old image, not the new image.

Reproducible: Always

Steps to Reproduce:
1.Save an image on desktop, e.g., named pic.jpg.
2.Start composer and drag/drop pic.jpg to composer; observe correct file.
3.Save a new image to desktop, but with same name pic.jpg.
4.Drag/drop new image pic.jpg to composer; however, old image will appear instead.

Actual Results:  
The old image is shown twice, rather than the old image followed by the new image.

Expected Results:  
The old image should be followed by the new image.

I did my best to follow 4 steps before entering bug report.  If I missed one and this is redundant then my apologies.

Comment 1

[rsx11m]

Yes, this has been reported before for the old branch, it's sometimes hard to find duplicates. Good to know though that the problem is still present.

Comment 2

[rsx11m]

Based on bug 404922 comment #3, the displayed image in the composition window appears to be working correctly on trunk (version 3.0) now, thus potentially different from the issue discussed there. Please feel free to reopen this if
it turns out to be of different cause and is still an issue in the 3.0 builds.

Also, the fact that two different images are eventually merged into the same (last version) one just because they share the same file path may be reason
for a separate bug, if none has been filed yet. Copy and paste through the clipboard would avoid this as it is creating its own temporary file, and since bug 444800 checked in, is also possible in lossless PNG quality on trunk.