Deleting the reference to a profile from a JSON fragment file prevents the profile from showing back up again even when the profile still exists in the fragment file.

[danmock]

Windows Terminal version

1.14.2282.0

Windows build number

10.0.22000.0

Other Software

No response

Steps to reproduce

1. Create a fragment file with a profile in it.
   • Absolute path: $Env:LocalAppData\Microsoft\Windows Terminal\Fragments\TestFragmentDir\testFragment.json
2. Launch Windows Terminal.
3. The profile from the fragment file appears in the profile drop down.
4. Close Windows Terminal.
5. Remove the reference to the testFragment.json profile from the settings.json file.
6. Launch Windows Terminal.
7. The profile from the fragment file does not appear in the profile drop down.
8. The fragment file with the profile in it still exists, along with the profile.

Expected Behavior

Either:

• Remove the profile from the fragment file testFragment.json in addition to the reference to said profile from the settings.json file.

or

• Upon reopening Windows Terminal after removing the reference to the testFragment.json profile from the settings.json file, the reference should reappear (as the fragment file containing the profile still exists).

Actual Behavior

As listed in Steps to reproduce.

---

Scenario where this is an issue:

• My team provides users a set of fragment files containing profiles (with very specific GUIDs).
  • The fragment files are automatically generated as part of a script which users execute.
  • These profiles define the CLIs which users must interact with for interfacing with a set of repositories.
• User U tinkers with their settings.json file, removing several profiles, including references to the profiles from the fragment files that we provided them.
• U no longer sees the profiles associated with the fragment files we gave them, even though the fragment files still exist and have not been modified.
• U alerts our team that they see the profiles in the fragment files, yet Windows Terminal won't show them.
• U informs that they are unable to access the CLIs associated with their work (as defined by the profiles in the fragment files).
• U deletes their repository, re-clones it, then generates the fragment files again, in an attempt to get Windows Terminal to show the CLIs for the repository.
• U smashes their keyboard into their monitor when nothing is working, and promptly leans back in their chair and contemplates their life choices.

[DHowett]

Thanks for filing this, @danmock. There's definitely a few things we could do to make this experience better.

Off the top of my head:

• Add an Extensions page to the SUI #10436 tracks adding a page where users can discover "extensions" (today that's only fragments, but it could also include future plugins ala Scenario: Add support for 3rd-party extensions #4000) and see what profiles/settings/color schemes they contributed. That would probably be a good place to nestle this "recover a deleted profile" feature.
• [megathread] Deleting profiles is often confusing #9997 tracks a number of other things we'd like to do to make the dynamic (that is, discovered at runtime) profile experience a bit easier and may be worth a read
• Today, users can recover any lost profiles in the poorly-named "Duplicate" section of the "Add new profile" page

As a stop-gap, do any of those things help?

We'll make sure to discuss this at a team meeting.

[lhecker]

I was about to write a response as well. To just state some things that @DHowett left unsaid: The specific PR which changed this is #11007. This change was quite important to make profile deletions less confusing. For instance Visual Studio 17.3 now ships with the "VSDebugConsole" fragment. Without this change it would be impossible to properly get rid of that profile for anyone who has Visual Studio installed. But if you do need it back it still shows up ready to be cloned at any time:

IMO, if anything, we should improve our UX in regards to profile creation to make the discovery of previously deleted profiles more obvious to users.

[danmock]

Are the deleted profiles from the Duplicate a profile dropdown cached copies of the profiles as they existed when they were deleted?

[DHowett]

This is where it gets weird, and why I'm not comfortable closing this out as "solved" or anything.

The profiles in that list are the actual "deleted" ones. There's a few boring and indepth reasons for that... but suffice it to say we still deserialize all of the fragments and dynamic profiles and everything before we choose which ones to show.

When you create one using Duplicate, though, you get a new profile, with a new GUID that is a deep copy of the original fragment. It's not connected to it any more. It's a weird ethereal plane version of the original fragment. ☹️

[danmock]

I see. For our use case that would be problematic since we require a specific GUID for the profile, for each profile.

[zadjii-msft]

another related thread: #11510

[zadjii-msft]

@DHowett So this... wasn't also closed by #18188?

[DHowett]

Correct! It’s backwards from the others - the user deletes their personal stub for a fragment and it never comes back (by design today, but Carlos’ Wxtensions page will help solve this.)