203847 - Make sure that dragged file is deleted from intermediate location

Status: RESOLVED FIXED

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

Description

[Nisheeth Ranjan]

See bug 97413 for background info.

The issue is that when an image is dragged from Mozilla to the 
desktop/explorer, the intermediate temp file is deleted because it is moved 
from the temp location to the final location.

But, when the same image is dragged into another app like IE or Photoshop, the 
intermediate file isn't deleted and clutters up the temp directory.

Comment 1

[Nisheeth Ranjan]

Attachment: First attempt at fix

This patch ensures that we delete the intermediate temp file once the drag/drop
operation is over.

Comment 2

[Nisheeth Ranjan]

Comment on attachment 125120 [details] [diff] [review]
First attempt at fix

Simon, please r=.
Kin, please sr=.

This patch makes sure that the temporary intermediate file is deleted after the
drag/drop operation is finished.

Comment 3

[Simon Montagu :smontagu]

The comment in nsDragService.cpp is unclear to me. Are we concerned about cases
where the DnD just fails or cases where the target, for mysterious reasons known
only to itself, doesn't make the call to IDataObject::SetData() that we expect?

If the latter, would adding a test for CFSTR_PASTESUCCEEDED as well as (or even
instead of) CFSTR_PERFORMEDDROPEFFECT work instead?

If the former, we should probably only call IDataObject::SetData() ourselves
when ::DoDragDrop returns a failure code.

Comment 4

[Nisheeth Ranjan]

OK, here are the different cases that I'm try to deal with:

1) Drag-drop on to app that accepts CF_HDROP (desktop or explorer).
2) Drag-drop onto an app that doesn't accept CF_HDROP but accepts some other
format (MS Dev Studio editor).
3) Drag-drop onto area that doesn't accept any format (you see the circular icon
with a line running through it diagonally when you drop).
4) Drag-drop is canceled by hitting escape.

I experimented to see when SetData() is called by the OS (after removing my hack
in nsDragService.cpp) with CFSTR_PERFORMEDDROPEFFECT and CFSTR_PASTESUCCEEDED
formats for each of above cases:

   CFSTR_PERFORMEDDROPEFFECT       CFSTR_PASTESUCCEEDED

1) Called                          Not called
2) Not called                      Not called
3) Not called                      Not called
4) Not called                      Not called

It seems that CFSTR_PASTESUCCEEDED is never called and CFSTR_PERFORMEDDROPEFFECT
is only called for one case.  It is to cover cases 2-4 that I put in the hack. 
I don't like it but I couldn't think of a better way...

I need to clean up the temporary intermediate file once the drag/drop operation
finishes regardless of whether it was successful or not.  Thats why I need the
code in nsDragService.cpp...

Comment 5

[Simon Montagu :smontagu]

Comment on attachment 125120 [details] [diff] [review]
First attempt at fix

OK, in that case I can't see a way to avoid this hack either. Can you just
expand the code comments in nsDragService.cpp so that it is clearer what cases
you are handling?

r=smontagu

Comment 6

[kinmoz]

Comment on attachment 125120 [details] [diff] [review]
First attempt at fix

sr=[e-mail]

Comment 7

[Nisheeth Ranjan]

Fix checked into trunk...

Comment 8

[Frank Wein [:mcsmurf]]

Bug 209593 seems to be caused by this checkin, can you take a look at that Bug?

Comment 9

[kinmoz]

Looks like the patch in this bug exposed a pre-existing problem in
InvokeDragSession() where the data objects weren't being addref'd and released
properly.

Comment 10

[Hermann Schwab]

Bug 218857 dragging image into explorer does only work once   seems also to be
caused by this bug, the reporter can drag once on Windows ME, I can´t drag at
all on Win98 and Win98SE, see bug 218857.
 
Mozilla  BuildID 2003061204 (working) 
Checkin Bug 203847 06/13/2003 13:38
Firebird BuildID 20030614   (failing)
Mozilla  BuildID 2003061608 (failing)