Closed Bug 1435755 Opened 6 years ago Closed 5 years ago

[Dedicated profiles] When cloning fails (e.g. file lock) and Firefox fails to start - start with clean profile

Categories

(Toolkit :: Startup and Profile System, defect, P3)

defect

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox-esr52 --- unaffected
firefox58 --- unaffected
firefox59 --- unaffected
firefox60 --- ?

People

(Reporter: aflorinescu, Unassigned)

References

Details

[Environment:]
-Ubuntu 16.04 x64
-Firefox 60.0a1 (trybuild from https://treeherder.mozilla.org/#/jobs?repo=try&revision=6b67fc750f609d3eaa4097528528458e43bb4873&selectedJob=158774545)
-Firefox 58.0.1	20180128191252



[Pre-requisites:]
Delete all Firefox data and cache.

[Steps:]
1. Start Firefox 58.0.1 (default profile is created)
2. Open profile directory and lock all access to it.
3. Open Nightly try-build containing the dedicated profile feature.


[Actual Result:]
" Firefox is already running, but is not responding. To open a new window, you must first close the existing Firefox process, or restart your system."
A profile2.ini is created, the default-nightly folder is created as well, with no data in it.


[Expected Result:]
When the cloning encounters issues and fails (I will also add exceeds a reasonable amount of time - given that we add or we don't add an interface), handle the error, drop the cloning and create an empty default-* profile, starting the browser using it.
Additional note for the above, since it enters the same category: when the Default release profile is opened - we can't clone it, we should drop the cloning and fire out a clean new default channel profile.
Summary: [Dedicated profiles] Cloning fails (file lock) and Firefox fails to start → [Dedicated profiles] When cloning fails (e.g. file lock) and Firefox fails to start - start with clean profile
I missed a step in the [Steps:] section, after step1 where FF 58.0.1 creates the "default" profile, the browser is closed, so the error message is thrown w/o having any Firefox instance open.
Priority: -- → P3

Due to the fact that Dedicated profiles per install implementation branched away into another approach (bug 1474285), this issue should probably be marked as invalid. However, due to the fact that might be the case that cloning might be considered at a future point, I'll mark it as won't fix.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.