415632 - Zero byte empty image passed to other programs via Drag & Drop.

Status: RESOLVED DUPLICATE of bug 494989

(Core :: DOM: Copy & Paste and Drag & Drop, defect)

Description

[Leo Davidson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11

If you drag & drop an image from Firefox to another Windows app then a zero byte empty file may result in the target application.

While it does work okay if you drop on Explorer (not surprising as it's probably what Firefox was tested against), I have looked into this problem in a debugger and it is clearly Firefox's fault, as I'll explain.

Firefox provides a drop object which points to a file with the image's name in the temp directory. That file does indeed exist, but it is empty at this time. Firefox does not write the file's data until *after* the other program has returned from the drop event, which is obviously too late. If Firefox is going to pass file paths to other programs then those files should already exist and be written to disk.

This also begs the question of how (or even if) those temp files get deleted. They seem to sit on disk forever (or until the OS cleans up the temp dir). The correct procedure for Win32 drag & drop using temp files is to create and write the temp files and their contents, then create the IDataObject, send the drop event to the other program and then wait until the IDataObject is released to delete the temp files.

(Note: That is another thing that many programs get wrong. They delete the temp files when the drop event returns, but the other program may still be using the IDataObject on another thread and have returned from the drop event to ensure its UI thread remains responsive while the data is copied. The ref-counted IDataObject COM object should control the lifetime of the tempfiles and associated data, not the drop event. Doing anything else can mean that the files don't exist at the right time, or they never get deleted (since the other program still has them locked), or that they are deleted too soon (before the other program has copied them on a separate thread). But this is a complete side issue to the more important fact that the files are empty at the time that Firefox passes the IDataObject to the other program.)

If you want to reproduce this then two programs you can use are the file managers, Directory Opus and Total Commander. I am personally involved with Directory Opus (more on the community/support side; I don't write the program itself) and will be happy to help in any way I can, as I know will GPSoftware who write Opus. I noticed that Total Commander was also affected by the problem when I did a web search to see if it was just us: http://ghisler.ch/board/viewtopic.php?t=5772


Reproducible: Always

Steps to Reproduce:
1.Display an image in Firefox.
2.Open Directory Opus or Total Commander (or many other apps, but not Explorer).
3.Drag the image from Firefox to the other application.

Actual Results:  
A zero byte, empty file is created with the image's filename.

If you use a debugger in the target program's drop handler, and also inspect the temp directory, you can see that when the drop handler is called the file is in the temp dir, but empty. It is not until you step through the code to the point that the drop handler returns that firefox actually writes data to the file.


Expected Results:  
The image's contents should be in the file that results from the drop (and in the temp file before the drop event is sent to the other program).

Comment 1

[jpotter]

This is probably the same underlying problem as https://bugzilla.mozilla.org/show_bug.cgi?id=414020

Comment 2

[Leo Davidson]

I've noticed this bug causing problems with Explorer itself as well now, at least when dropping large images on the Desktop on my Vista (32-bit SP1) machine.

With large files I often end up with a 0 byte JPG instead and have to delete that and try the drag & drop again to make it work.

Comment 3

[Phil Lacy]

There's a patch on this in a tree of patches that fixes this and other drag and drop problems.