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

RESOLVED FIXED in mozilla1.9.1b1

Status

()

P1
critical
RESOLVED FIXED
14 years ago
7 years ago

People

(Reporter: jcoutch, Assigned: mayhemer)

Tracking

({dataloss})

unspecified
mozilla1.9.1b1
x86
Windows 2000
dataloss
Points:
---
Dependency tree / graph
Bug Flags:
wanted1.9.0.x -
wanted1.8.1.x +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 4 obsolete attachments)

(Reporter)

Description

14 years ago
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

14 years ago
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

14 years ago
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)
Darin or Doug: is this something you could look into?

Comment 4

14 years ago
This could be a bug in Windows Explorer or Firefox, but it doesn't sound like a
security hole in either.
Group: security
Summary: When file dragged from FTP into Firefox window, it deletes it!!! → Dragging file from Windows Explorer FTP into Firefox deletes the file.

Updated

14 years ago
Keywords: dataloss

Comment 5

11 years ago
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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8.1.15?
Flags: blocking-firefox3?
Priority: -- → P1
Target Milestone: --- → Firefox 3
This will not block the final release of Firefox 3. Any patch will need unit tests in order to be approved.
Flags: wanted-firefox3+
Flags: blocking-firefox3?
Flags: blocking-firefox3-
Flags: wanted1.9.0.x+
Will look at whatever patch the trunk eventually takes but not blocking 2.0.0.x
Flags: blocking1.8.1.15? → wanted1.8.1.x+
(Assignee)

Comment 9

11 years ago
--> me, will try to fix this
Assignee: nobody → honzab
(Assignee)

Comment 10

11 years ago
Created attachment 330408 [details] [diff] [review]
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.
Attachment #330408 - Flags: review?(mconnor)
(Assignee)

Updated

11 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 11

11 years ago
Created attachment 330476 [details] [diff] [review]
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.
Attachment #330408 - Attachment is obsolete: true
Attachment #330476 - Flags: review?(mconnor)
Attachment #330408 - Flags: review?(mconnor)
(Assignee)

Updated

11 years ago
Attachment #330476 - Flags: review?(mconnor) → review?(emaijala)
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?
Attachment #330476 - Flags: review?(emaijala) → review-
(Assignee)

Updated

11 years ago
Depends on: 26767
(Assignee)

Comment 13

11 years ago
Created attachment 330841 [details] [diff] [review]
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.
Attachment #330476 - Attachment is obsolete: true
Attachment #330841 - Flags: review?(emaijala)
Comment on attachment 330841 [details] [diff] [review]
Ftp file delete and display fix, v2

Please rename mPreferredMove to mMovePreferred and I'm happy.
Attachment #330841 - Flags: review?(emaijala) → review+
(Assignee)

Comment 15

10 years ago
Created attachment 335552 [details] [diff] [review]
Ftp file delete and display fix, v3

Fixed mPreferredMove -> mMovePreferred.
Attachment #330841 - Attachment is obsolete: true
Attachment #335552 - Flags: review+
(Assignee)

Comment 16

10 years ago
Is there still need to have 1.8 patch?
Keywords: checkin-needed
patch failed to apply
Keywords: checkin-needed
Target Milestone: Firefox 3 → ---
(Assignee)

Comment 18

10 years ago
Created attachment 337719 [details] [diff] [review]
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.
Attachment #335552 - Attachment is obsolete: true
Attachment #337719 - Flags: review+
(Assignee)

Updated

10 years ago
Keywords: checkin-needed
Component: File Handling → Widget: Win32
Flags: wanted-firefox3+
Flags: blocking-firefox3-
Product: Firefox → Core
QA Contact: file.handling → win32
http://hg.mozilla.org/mozilla-central/rev/087dfa16ea19
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1b1
(Assignee)

Comment 20

10 years ago
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.

Updated

10 years ago
Depends on: 454843
(Assignee)

Updated

10 years ago
No longer depends on: 454843
Flags: wanted1.9.0.x+ → wanted1.9.0.x-
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?

Updated

9 years ago
Depends on: 573321
> 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.
Blocks: 679196
(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. :)
No longer blocks: 679196
Depends on: 679196
You need to log in before you can comment on or make changes to this bug.