Closed Bug 1442200 Opened 2 years ago Closed 2 years ago

"Don't Delete Files" option from about:profiles deletes the selected profile folder.

Categories

(Toolkit :: Startup and Profile System, defect)

58 Branch
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla61
Tracking Status
firefox-esr52 --- unaffected
firefox58 --- wontfix
firefox59 --- wontfix
firefox60 --- verified
firefox61 --- verified

People

(Reporter: zstimi, Assigned: baku)

References

Details

(Keywords: dataloss, regression)

Attachments

(1 file)

[Affected versions]:
Firefox 59.0b13 (Build Id:20180226180053)
Firefox 60.0a1  (2018.02.28)

[Unaffected versions]:
Firefox 57.0 (Build Id:20171112125346)

[Affected platforms]:
Windows 8.1 x64
Mac OS 10.13.4
Ubuntu 14.04 x64

[Steps to reproduce]:
1.Launch Firefox.
2.Go to about:profiles in URL.
3.Create some new profiles if you don't have yet.
4.On about:profiles page, select a profile you want to delete by clicking the "Remove" button for it. On "Delete Profile" prompt , select the "Don't Delete Files" button. "Don't Delete Files" is the preferred option because it saves the old profile's folder and allows you to recover the files to a new profile. 

[Expected result]:
This option shouldn't delete the folder: “C:\Users\XXX\AppData\Roaming\Mozilla\Firefox\Profiles\dycc44f4.test”

[Actual result]:
"Don't Delete Files" option deletes the selected profile folder.
This doesn't reproduce while performing the same steps in Profile Manager. Start the Profile Manager when Firefox is closed, the profile folder and its files are not deleted.

[Regression range]:
This seems to be a regression:
Last good build: 2017.10.12
First bad build: 2017.10.13
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4baaea004689e8f6f4a4d9feff99c98c5378c3ce&tochange=6c0e229ac2e85888be179d3126f51ff392b05eea
Bug 1305230 - Splitting test_fileapi_slice in two files, r=qdot
Bug 1406818 - about:profile uses nsIToolkitProfile.removeInBackground, r=ehsan
Flags: needinfo?(amarchesini)
Attached patch profile.patchSplinter Review
Assignee: nobody → amarchesini
Flags: needinfo?(amarchesini)
Attachment #8957494 - Flags: review?(ehsan)
Attachment #8957494 - Flags: review?(ehsan) → review+
Pushed by amarchesini@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/3af13e1ae15a
about:profiles passes a removeFiles boolean param to nsIToolkitProfile::removeInBackground, r=ehsan
https://hg.mozilla.org/mozilla-central/rev/3af13e1ae15a
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
Seems like this would be a good uplift candidate once verified on Nightly.
Blocks: 1406818
Flags: qe-verify+
Flags: needinfo?(timea.zsoldos)
Keywords: dataloss
I can confirm this issue is fixed, I verified using Firefox Latest Nightly 61.0a1 (2018.03.14) on Win 8.1 x64, Ubuntu 14.04 x64 and Mac OS X 10.12.6.
Flags: needinfo?(timea.zsoldos)
This has been verified on Nightly. Please request Beta approval on this when you're ready to do so.
Status: RESOLVED → VERIFIED
Flags: needinfo?(amarchesini)
Comment on attachment 8957494 [details] [diff] [review]
profile.patch

Approval Request Comment
[Feature/Bug causing the regression]: about:profiles
[User impact if declined]: the profile directory is always deleted also when the user doesn't want.
[Is this code covered by automated tests?]: no
[Has the fix been verified in Nightly?]: yes
[Needs manual test from QE? If yes, steps to reproduce]: follow the description of the bug
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: no
[Why is the change risky/not risky?]: Just a boolean propagated.
[String changes made/needed]:
Flags: needinfo?(amarchesini)
Attachment #8957494 - Flags: approval-mozilla-beta?
Comment on attachment 8957494 [details] [diff] [review]
profile.patch

fix for about:profiles, beta60+
Attachment #8957494 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
I can confirm this issue is fixed, I verified using Firefox 60.0b5 on Windows 8.1 x64, Ubuntu 14.04 x64 and Mac OS X 10.13.2.
Flags: qe-verify+
Do we have an automated test to prevent it from happening again?
We don't have any test for about:profiles nor for nsIToolkitProfile.
You need to log in before you can comment on or make changes to this bug.