Closed Bug 1417096 Opened 7 years ago Closed 6 years ago

firefox "Download" bug , "Delete files stealthily"

Categories

(Firefox :: Downloads Panel, defect, P3)

57 Branch
defect

Tracking

()

RESOLVED DUPLICATE of bug 1474765
Tracking Status
firefox-esr52 --- unaffected
firefox57 --- affected
firefox58 --- affected
firefox59 --- affected

People

(Reporter: yyy5357, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171112125346

Steps to reproduce:

(I am not a developer and my English is not good.)
Firefox57.0x64 Chinese (Simplified),win10x64, Bug:
For example:
1.Download "123.txt" to "D:\123.txt", Cancel it before downloaded.
2.Create a file,or Copy a file, to "D:\" , and rename it to "D:\123.txt".
3.Click the "remove the entry from the list" or "Clear Downloads".
(3.If in "Private Window",it is simpler, just close the "Private Window" )
4.The "D:\123.txt" has been Deleted !!!
That is not good !
The "D:\123.txt" should not be deleted !!!


Actual results:

The "D:\123.txt" has been Deleted !!!


Expected results:

The "D:\123.txt" should not be deleted !!!
(In reply to k9fvmfsyb8a3g from comment #0)
> User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0)
> Gecko/20100101 Firefox/57.0
> Build ID: 20171112125346
> 
> Steps to reproduce:
> 
> (I am not a developer and my English is not good.)
> Firefox57.0x64 Chinese (Simplified),win10x64, Bug:
> For example:
> 1.Download "123.txt" to "D:\123.txt", Cancel it before downloaded.
> 2.Create a file,or Copy a file, to "D:\" , and rename it to "D:\123.txt".
> 3.Click the "remove the entry from the list" or "Clear Downloads".
> (3.If in "Private Window",it is simpler, just close the "Private Window" )
> 4.The "D:\123.txt" has been Deleted !!!
> That is not good !
> The "D:\123.txt" should not be deleted !!!
> 
> 
> Actual results:
> 
> The "D:\123.txt" has been Deleted !!!
> 
> 
> Expected results:
> 
> The "D:\123.txt" should not be deleted !!!

Another example:
1.Through a link,or click a link-button , to Download "456.zip" to "D:\456.zip", and Click "Cancel“ before it downloaded.
2.The "D:\456.zip" and "D:\456.zip.part" have been Deleted. It is good !
3.Through the same link ,or click the same link-button ,to Download "456.zip" to "D:\456.zip", and download it done.
(Don't do this :
"Retry a Download : If for any reason a file does not finish downloading, click the button to the right of the entry - a refresh symbol - to retry. ")
4.We got a file "D:\456.zip". It is good !
5.Click the "remove the entry from the list" or "Clear Downloads".
(5.If in "Private Window",it is simpler, just close the "Private Window" )
6.The "D:\456.zip" has been Deleted !!! It is not good !!!

Actual results:

When Click "Cancel“ ,the files have been Deleted already. It is good !
When Delete the download-list , the files with same name were Deleted once Again . It is not good !!!

Expected results:

When Click "Cancel“ ,the files have been Deleted already. So:
When Delete the download-list , just Clear the list , DO NOT Delete any files !
Because, maybe the files are not the same files , they are just same name.
And even if they are same files , the flles should not be deleted !
I was able to reproduce the described behaviour on these platforms and versions:

1.
  Build ID: 20171115114231
  OS: Debian 9.2
  Version: 58.0b4

2. 
  Build ID: 20171115114231
  OS: Windows 10.0.17025
  Version: 58.0b4	

3.
  Build ID: 20171115114231
  OS: Windows 10.0.17025
  Version: 58.0b4 (Developer Edition) 	

4.  
  Build ID: 20171117100127
  OS: Windows 10.0.17025
  Version: 59.0a1

I was *unable* to reproduce the bug with the following Setup:

1.  
  Build ID: 20171114221957
  OS: Debian 9.2
  Version: 52.5.0 (ESR)
Status: UNCONFIRMED → NEW
Ever confirmed: true
3rd example : 

About my 1st example:

[   3.Click the "remove the entry from the list" or "Clear Downloads".
   (3.If in "Private Window",it is simpler, just close the "Private Window" )    ]

If do this :
 "Click the button to the right of the entry - a refresh symbol" .

Then :
The file "D:\123.txt" will be replaced .
(Same as "Delete the old 123.txt and Create a new 123.txt")

But :
This "D:\123.txt" is NOT that "D:\123.txt" . Maybe the old 123.txt is important .
--------

All of my 3 examples :
Deleting files stealthily let me have no sense of security .
Summary: firefox 57.0 about "Download" bug → firefox 57.0 about "Download" bug , "Delete files stealthily"
Summary: firefox 57.0 about "Download" bug , "Delete files stealthily" → firefox "Download" bug , "Delete files stealthily"
Priority: -- → P3
University of Toronto 3rd year student here working through a software engineering course (CSC302). The current assignment is to fix a GFB and I have chosen this one.

This bug breaks user trust when FF over reaches its boundaries as it locally clears its own record of downloaded files by actually removing the file from the user's file system. I believe this is not what the "Clear downloads"/closing a Private Window intends to do as it seems to inherit the behaviour of clearing one's history which different than clearing the recorded history of downloads.

This feature should instead clean up FF's own recorded history of downloaded files while keeping files that have the same name or were later fully downloaded. It is important user's have a sense of trust in FF's intentions in handling the files they download because, as one example, users with limited bandwidth may be deeply affected by having to re-download files that were erroneously removed when simply wanting to clear FF's recorded list of files.

I hope to rectify this error in FF as my first contribution to an open source project.

- GW
Hi Grant! Let's just make sure this is indeed a good first bug.

Hey paolo, do you think this bug is ready for Grant to work on, or should we find him something else?
Flags: needinfo?(paolo.mozmail)
Hi Grant and Mike, this is not a good first bug, primarily because it is broad in scope and, while it states a problem, a narrow and simple solution has not been identified in the bug yet.

After looking at comment 0 again, the core issue here seems to boil down to what has been reported later in bug 1474765. This would be good to improve but is very difficult to do, given the possible variations mentioned in bug 1474765 comment 4. An incorrect fix may leave the target location obstructed by a partial download, leaving users with corrupted files even if they didn't manipulate the download directory, which in many cases may be worse than having to re-download from the source.

You can find a list of good first bugs at <https://codetribute.mozilla.org/projects/ff?tag%3Dgood-first-bug>. Hope this helps!
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(paolo.mozmail)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.