Skip to content

Don't clobber NewTerminalArgs settings when initializing a tab - #20810

Open
Mike Griese (zadjii-msft) wants to merge 3 commits into
mainfrom
dev/migrie/b/20749
Open

Mike Griese (zadjii-msft) wants to merge 3 commits into
mainfrom
dev/migrie/b/20749

Conversation

@zadjii-msft

Copy link
Copy Markdown
Member

#20328 added a call to Tab::UpdateSettings in _InitializeTab so that the tab header would pick up the window's tabWidthMode (previously done in Tab::Initialize via the global settings).

HOWEVER, UpdateSettings also pushes profile-only settings into every pane, overwriting settings that came from NewTerminalArgs (e.g. CLI args like --suppressApplicationTitle, --colorScheme, etc).

Instead, pass the window settings into Tab::Initialize and only update the header width there, like it was before #20328.

Closes #20749

Related to #20751

#20328 added a call to Tab::UpdateSettings in _InitializeTab so that the tab header would pick up the window's tabWidthMode (previously done in Tab::Initialize via the global settings). However, UpdateSettings also pushes profile-only settings into every pane, overwriting settings that came from NewTerminalArgs (e.g. --suppressApplicationTitle, --colorScheme).

Instead, pass the window settings into Tab::Initialize and only update the header width there, like it was before #20328.

Closes #20749

@lhecker Leonard Hecker (lhecker) left a comment •

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two? nits? LGTM.

VERIFY_ARE_EQUAL(til::color{ 0xff000000 }, backgroundColor);
});
Log::Comment(L"Sleep to let events propagate");
Sleep(250);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test is sus. Could probably be part of an existing test?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean, maybe? I don't hate that it's an actually pretty specific test for the original regression.

It's more of a bigger issue that every "UI" test we write needs to add a 250ms wait at the end to make sure things worked.

we have like, insanely low test coverage for how our UI works so I'm kinda inclined to add more

ASSERT_UI_THREAD();

// GH#20749: Only apply the tab-level window settings here. Don't call
// UpdateSettings, because that would also push profile-only settings

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eh? Why does UpdateSettings override those launch args in the first place?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly historical reasons I guess. There's been a bug on the backlog for ages for "hot reloading the settings can clobber CLI args". I wanted to scope this fix down to just fixing this bug rather than ((however big that fix ends up being))

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

per-window-settings breaks --suppressApplicationTitle

2 participants