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

RESOLVED FIXED in Firefox 67

Status

()

defect
RESOLVED FIXED
2 months ago
a month ago

People

(Reporter: adrian_sv, Assigned: mossop, NeedInfo)

Tracking

Trunk
mozilla67
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr60 wontfix, firefox65 wontfix, firefox66 wontfix, firefox67+ fixed)

Details

Attachments

(3 attachments)

(Reporter)

Description

2 months ago

[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.

(Assignee)

Comment 1

2 months ago

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
(Assignee)

Comment 2

2 months ago
Posted 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)
(Assignee)

Comment 3

2 months ago

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.

Updated

2 months ago
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)

Comment 5

2 months ago
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

Comment 7

2 months ago
bugherder
Status: NEW → RESOLVED
Last Resolved: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67

Comment 8

2 months ago
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)

Updated

2 months ago
Depends on: 1534186

Comment 11

2 months ago
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 → ---
(Assignee)

Comment 12

2 months ago

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
Last Resolved: 2 months ago2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
(Assignee)

Updated

a month ago
Duplicate of this bug: 1538240
You need to log in before you can comment on or make changes to this bug.