296528 - Dragging file from Windows Explorer FTP into Firefox deletes the file.

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect, P1)

Description

[jcoutch]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322; .NET CLR 1.0.3705)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

When I drag a file from an FTP site (that I have read/write access to) into 
Mozilla Firefox, it deletes it from the FTP without asking!!!  This has 
happened with any version of Firefox I have used.

Reproducible: Always

Steps to Reproduce:
1. Log into an FTP site using either Windows Explorer or Internet Explorer
2. Find a file that you wish to view in Firefox
3. Drag the file from the Explorer window into Firefox
4. Watch your file disappear from Explorer!
5. Refresh the Explorer window, and the file is not there.  It has been deleted 
off the server.

Actual Results:  
The file was deleted off the FTP

Expected Results:  
If I drag a local file from my hard drive into Firefox, it loads it.  If I run 
IE, and drag a file from an FTP into it, it loads the page from the FTP.  This 
is what Firefox should do too.  I have no problem logging in a second time to 
the FTP through Firefox...I just don't like it deleting my files :).

Comment 1

[chris hofmann]

what happens when you drag the file from IE, to any other ftp client.  Is it
possible that IE also remove the file after the drag completes and the file is
"handed off" to the other application?

Comment 2

[chris hofmann]

another interest side test would be to check out what happens in the reverse
direction (e.g. drag ftp file from firefox and drop on IE)

Comment 3

[Daniel Veditz [:dveditz]]

Darin or Doug: is this something you could look into?

Comment 4

[Jesse Ruderman]

This could be a bug in Windows Explorer or Firefox, but it doesn't sound like a
security hole in either.

Comment 5

[Y.MOCHI]

I experience same phenomenon.

In first comment,
> Steps to Reproduce:
> 1. Log into an FTP site using either Windows Explorer or Internet Explorer

Case of me, happened "Mobile Device", not FTP.
I connect a mobile phone to my PC, through "Active Sync 4.5".
Then I drag a file from "Mobile Device" icon in the explorer window, and drop into Firefox.
The file is deleted, I cannnot find the file anywhere.

Comment 6

[Mitchell Field [:Mitch]]

Confirmed. Dragging a file from an FTP site via Internet Explorer 7, onto both Firefox 2.0.0.12 and Firefox 3 trunk, on Windows XP, deletes the source file.

Comment 7

[Mike Beltzner [:beltzner, not reading bugmail]]

This will not block the final release of Firefox 3. Any patch will need unit tests in order to be approved.

Comment 8

[Daniel Veditz [:dveditz]]

Will look at whatever patch the trunk eventually takes but not blocking 2.0.0.x

Comment 9

[Honza Bambas (:mayhemer)]

--> me, will try to fix this

Comment 10

[Honza Bambas (:mayhemer)]

Attachment: File deletion fix, v1

This is very simple fix that disallow drop to finalize when an error during a drop handling occurs. It occurs in case of dragging a file from FTP explorer what prevents any action on Firefox side but signals success to the drag source. Because we set DROPEFFECT_MOVE as resulting effect of the drag the file is deleted from the ftp server.

There are IMHO other two issue to be fixed:
1. Because win explorer sets DROPEFFECT_MOVE as possible effect of drag it is our responsibility to recognize it should not be the default operation. Currently I don't know how except parsing the URL directly.

2. There is an issue when handling the URL in form of ftp://ftp.foo.com/bar.txt. It is either badly sent from win explorer or badly handled by Firefox.

Comment 11

[Honza Bambas (:mayhemer)]

Attachment: Ftp file delete and display fix

This is real fix for the problems:
- merges preferred effect with the one set by the source. in case of drag from FTP explorer it doesn't contain DROPEFFECT_MOVE and therefor the file is not moved (deleted) when dropped
- handles CFSTR_INETURL ascii URL data. unicode URL is not provided by FTP explorer. this allows display of file as expected
- as previous patch, catches any exception while get data on transferable fails to prevent misbehavior in future

There is still one issue: ftp://ftp.foo.com/bar.txt URL is appended a slash. It prevents display of the file. I experience the same while browsing an ftp site and clicking a file to see it.

Comment 12

[Ere Maijala (slow)]

Comment on attachment 330476 [details] [diff] [review]
Ftp file delete and display fix

+          dump("nsTransferable.get() thrown exception");

"threw exception".

+    loadResult = GetNativeDataOffClipboard(inDataObject, inIndex, ::RegisterClipboardFormat(CFSTR_INETURL), &tempOutData, &tempDataLen);
+    if ( NS_SUCCEEDED(loadResult) && tempOutData ) {
+      nsDependentCString urlStringA(static_cast<char*>(tempOutData));
+      NS_ConvertUTF8toUTF16 urlString(urlStringA);

Is CFSTR_INETURL really UTF-8?

+      pIDataSource, 0, ::RegisterClipboardFormat("Preferred DropEffect"), &tempOutData, &tempDataLen);

Use CFSTR_PREFERREDDROPEFFECT instead of "Preferred DropEffect".

+    WORD prefferedEffect = *((WORD*)tempOutData);

Fix the spelling of "preferred".

+    // Mask effect comming from function call with effect preferred by the source.

Fix the spelling of "comming". 

+    *pdwEffect &= (DWORD)prefferedEffect;

So if the source prefers DROPEFFECT_COPY, there would be no way of actually doing a move. We don't really want that, do we?

Comment 13

[Honza Bambas (:mayhemer)]

Attachment: Ftp file delete and display fix, v2

Reflecting all comments. According to the last one about complete inhibition of move - I tried to move file from FTP to disk. It moves the file while I hold shift so I implemented the same behavior to be in Firefox.

Also I was testing with patch from bug 26767 to and i18n names. The patch seems not to be completed but debugging shows the way of using NS_CopyNativeToUnicode is correct.

Comment 14

[Ere Maijala (slow)]

Comment on attachment 330841 [details] [diff] [review]
Ftp file delete and display fix, v2

Please rename mPreferredMove to mMovePreferred and I'm happy.

Comment 15

[Honza Bambas (:mayhemer)]

Attachment: Ftp file delete and display fix, v3

Fixed mPreferredMove -> mMovePreferred.

Comment 16

[Honza Bambas (:mayhemer)]

Is there still need to have 1.8 patch?

Comment 17

[Dão Gottwald [:dao]]

patch failed to apply

Comment 18

[Honza Bambas (:mayhemer)]

Attachment: v3, merged

This is merged version that applies now. I removed the try/catch block in nsDragAndDrop.js because it seems not to be any longer applicable.

Comment 19

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/087dfa16ea19

Comment 20

[Honza Bambas (:mayhemer)]

By the way, now this bug really fixes just the deletion problem. Files on FTP server drop from windows explorer are no longer appearing in firefox but when I was originally working on this bug it used to work. Not perfectly but at least in most cases.

This is exception in the console:

JavaScript error: chrome://global/content/nsDragAndDrop.js, line 458: transferData.first is null

It appears either my patch is applied or not.

Comment 21

[Jim Mathies [:jimm]]

What was the purpose of this assert in this patch:

NS_ASSERTION(tempDataLen == 2, "Expected word size");

This fires fairly regularly on drags of links, because nsClipboard's GetNativeDataOffClipboard's default fall through may return 0 for length in the case of a zero length string result.

Can we disable this safely?

Comment 22

[Brian R. Bondy [:bbondy]]

> Can we disable this safely?

Jim, I know it's been nearly 2 years since you asked, but I  I answered your question from Comment 21 in Bug 573321 :)  Hope it is still of interest to you.

Comment 23

[Jim Mathies [:jimm]]

(In reply to Brian R. Bondy [:bbondy] from comment #22)
> > Can we disable this safely?
> 
> Jim, I know it's been nearly 2 years since you asked, but I  I answered your
> question from Comment 21 in Bug 573321 :)  Hope it is still of interest to
> you.

Thanks. :)