Closed Bug 1530615 Opened 1 year ago Closed 1 year ago

[Dedicated Profiles] Two profiles are being shown as being in use

Categories

(Toolkit :: Startup and Profile System, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla67
Tracking Status
firefox-esr60 --- wontfix
firefox65 --- wontfix
firefox66 --- wontfix
firefox67 + fixed

People

(Reporter: aflorinescu, Assigned: mossop)

References

Details

Attachments

(3 files)

[Environment:]
*Windows 10, Windows 7, Osx 10.14
*67.0a1 20190225102402

[Description:]
Although the steps to reproduce this are on the edge case side, there might be other paths that could generate this reported behavior.

[Steps to reproduce:]

  1. Clean environment (not absolutely necessary, just simplifies the test case and helps keeping track of the profiles)
  2. Install/extract Firefox with dedicated profiles.
  3. Start Firefox with dedicated profiles. (without using profile manager)
  4. Using about:support open the profile location.
  5. Close firefox while keeping open the profile location in a folder explorer.
  6. Delete physically the profile folder that Firefox has created as dedicated profile.
  7. Start Firefox with dedicated profiles. (with or without using profile manager) - just select the default-nighty profile.
  8. After step 7 fails, as expected with "Your profile cannot be loaded. It may be missing or inaccessible.", start Firefox Profile manager and create a new profile.
  9. Start Firefox with the new profile created at previous step and open about:profiles.

[Actual Result:]
*In about:profiles, @ step 9, two profiles are listed as in use and cannot be deleted: "default-nightly"(the deleted folder profile) and the one newly created after the "Your profile cannot be loaded... "
see: https://imgur.com/aC1SiEN

[Expected Result:]
Only the 2nd profile should be shown in use.

This looks like a regression from bug 1438620 and is reproducible on current release builds. The main issue stems from Firefox not verifying that profiles listed in profiles.ini actually exist on disk anymore. I'm loathe to add a check for that in startup as it will add some checks that may impact performance, we could do that check in about:profiles though.

Assignee: nobody → dtownsend
Blocks: 1438620
No longer blocks: 1474285
Attached image Example display

Michael, I'd like a decision of what to do in this case. What's happening is that Firefox has a profile in its list of known profiles, but the user has deleted the directory for that profile. I can't just detect this on startup because it would include a performance cost that the perf team would rather avoid.

There are a few straightforward fixes that I can do.

  1. When opening about:profiles we do a quick check of all the profiles and remove any that miss their directories from the list of known profiles.
  2. When opening about:profiles just exclude any that miss their directories from the list, the profile still remains in the list of known profiles.
  3. Show the bad profile in the list but display a message explaining that it cannot be used (would want wording in this case).
  4. Continue showing the profile and don't display any message. If the user attempts to use the profile, re-create the directory for the profile.

The latter is sort of tempting since it would fix another bug where if Firefox ends up with a profile with a missing directory we display a kinda nasty message on startup.

What is your preference?

Flags: needinfo?(mverdi)

This is about the simplest fix possible. Anything else would require strings so
I want to wait on UX before implementing that. This simply don't consider a
profile locked if the directory doesn't exist and doesn't show options to open
the directories if they don't exist.

See Also: → 1529879

(In reply to Dave Townsend [:mossop] (he/him) from comment #2)

What is your preference?

I think we should do the first option:

  1. When opening about:profiles we do a quick check of all the profiles and remove any that miss their directories from the list of known profiles.

If you deleted the folders on purpose, this would likely be the expected result.

Flags: needinfo?(mverdi)
Pushed by dtownsend@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c76f213ca5bd
Don't show a missing profile as in use in about:profiles. r=Gijs
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
Pushed by dtownsend@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/455e57b39067
Remove missing profiles from the profile service when showing the profile manager or about:profiles. r=Gijs

I verified this on Mac OS X 10.14, Windows 10, Ubuntu 16.04 with FF Nightly 67.0a1(2019-03-08) and I can't reproduce the issue, although I will leave a NI? to be sure that I will verify this scenario after other bugs related with the same problem are fixed and no regressions are introduced.

Status: RESOLVED → VERIFIED
Flags: needinfo?(ovidiu.boca)
Depends on: 1534186
Backout by dtownsend@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/0d5adb2cf4c9
Backed out changeset 455e57b39067 from bug 1530615 for causing bug 1534186. r=backout
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla67 → ---

Resolving is because the basic UI issue was fixed with https://hg.mozilla.org/mozilla-central/rev/c76f213ca5bd, the follow-up fix (that caused bug 1534186) made things nicer and less confusing to most users. But I guess we can't have nice things.

Status: REOPENED → RESOLVED
Closed: 1 year ago1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
Duplicate of this bug: 1538240
Flags: needinfo?(ovidiu.boca)
You need to log in before you can comment on or make changes to this bug.