One broken stub in a fragment file causes the whole file to not load #15340

Closed
opened 2026-01-31 04:35:39 +00:00 by claunia · 3 comments
Owner

Originally created by @PankajBhojwani on GitHub (Sep 24, 2021).

Originally assigned to: @lhecker on GitHub.

Windows Terminal version (or Windows build number)

Current main build

Other Software

No response

Steps to reproduce

Put the following fragment file in AppData\Local\Microsoft\Windows Terminal\Fragments\{any-name-here}:

{
  "profiles": [
    {
      "name": "broken profile",
      "font": "thisFontDoesntExist"
    },
    {
      "name": "Cool Profile"
    }
  ]
}

Then start WT

Expected Behavior

"Cool Profile" should show up in the dropdown

Actual Behavior

"Cool Profile" does not show up, the presence of the broken profile causes the non-broken profile to not load

Originally created by @PankajBhojwani on GitHub (Sep 24, 2021). Originally assigned to: @lhecker on GitHub. ### Windows Terminal version (or Windows build number) Current main build ### Other Software _No response_ ### Steps to reproduce Put the following fragment file in `AppData\Local\Microsoft\Windows Terminal\Fragments\{any-name-here}`: ``` { "profiles": [ { "name": "broken profile", "font": "thisFontDoesntExist" }, { "name": "Cool Profile" } ] } ``` Then start WT ### Expected Behavior "Cool Profile" should show up in the dropdown ### Actual Behavior "Cool Profile" does not show up, the presence of the broken profile causes the non-broken profile to not load
claunia added the Resolution-Fix-CommittedArea-SettingsIssue-BugProduct-Terminal labels 2026-01-31 04:35:39 +00:00
Author
Owner

@lhecker commented on GitHub (Sep 27, 2021):

The new code is consistent with the previous behavior. You can try it with:

{
    "profiles": [
        {
            "name": "broken profile",
            "unfocusedAppearance": ""
        },
        {
            "name": "Cool Profile"
        }
    ]
}

I'll tag this issue as needs-discussion, as we'd have to decide what the new failure handling would need to look like. After all, errors in the user's settings.json aren't just silently ignored either. A warning might be appropriate here...

@lhecker commented on GitHub (Sep 27, 2021): The new code is consistent with the previous behavior. You can try it with: ```json { "profiles": [ { "name": "broken profile", "unfocusedAppearance": "" }, { "name": "Cool Profile" } ] } ``` I'll tag this issue as needs-discussion, as we'd have to decide what the new failure handling would need to look like. After all, errors in the user's settings.json aren't just silently ignored either. A warning might be appropriate here...
Author
Owner

@PankajBhojwani commented on GitHub (Sep 27, 2021):

I have a branch pre-#11184 and with that example, "Cool Profile" loads while "broken profile" does not, so I think this was a recent regression! In #10601 we added try-catch blocks around the individual profile and update stubs within a fragment file to ensure we continue parsing fragments even if we find broken ones, which I believe the new implementation is missing.

We decided to silently ignore issues in fragment parsing because fragment issues are rarely the fault of the user, so we didn't think there was any point in alerting the user about that. Totally down to brainstorm other ways to avoid silently failing though

@PankajBhojwani commented on GitHub (Sep 27, 2021): I have a branch pre-#11184 and with that example, `"Cool Profile"` loads while `"broken profile"` does not, so I think this was a recent regression! In #10601 we added try-catch blocks around the _individual_ profile and update stubs within a fragment file to ensure we continue parsing fragments even if we find broken ones, which I believe the new implementation is missing. We decided to silently ignore issues in fragment parsing because fragment issues are rarely the fault of the user, so we didn't think there was any point in alerting the user about that. Totally down to brainstorm other ways to avoid silently failing though
Author
Owner

@lhecker commented on GitHub (Sep 27, 2021):

@PankajBhojwani Ah I see. I was testing with the wrong version of WT... I'll sneak a fix for this into #11343.

@lhecker commented on GitHub (Sep 27, 2021): @PankajBhojwani Ah I see. I was testing with the wrong version of WT... ~I'll sneak a fix for this into #11343.~
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#15340