Closed
Bug 1417096
Opened 7 years ago
Closed 6 years ago
firefox "Download" bug , "Delete files stealthily"
Categories
(Firefox :: Downloads Panel, defect, P3)
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 !!!
Component: Untriaged → Downloads Panel
(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 !
Comment 2•6 years ago
|
||
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)
Updated•6 years ago
|
status-firefox57:
--- → ?
status-firefox58:
--- → affected
status-firefox59:
--- → affected
status-firefox-esr52:
--- → unaffected
Updated•6 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•6 years ago
|
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"
Updated•6 years ago
|
Priority: -- → P3
Comment 4•6 years ago
|
||
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
Comment 5•6 years ago
|
||
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)
Comment 6•6 years ago
|
||
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.
Description
•