Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow empty strings, %Environment-Variable% references in profile "icon" settings - fixes #1468, #1867 #2050

Merged
merged 6 commits into from
Jul 25, 2019

Conversation

metathinker
Copy link
Contributor

@metathinker metathinker commented Jul 20, 2019

Summary of the pull request

Previously, trying to set the "icon" property of a settings profile to either the empty string or a string containing %environment variable names% would cause Terminal to crash when loading that profile into the profile selection menu. Now, empty strings for "icon" are treated the same as JSON null or not setting the property at all, and environment variable references in the "icon" value are expanded.

Detailed description of the pull request / Additional comments

To expand environment variables, I first tried reusing the existing ExpandEnvironmentVariableStrings() helper in TerminalApp/CascadiaSettings.cpp, but then I remembered that the Windows Implementation Libraries already provide their own wrapper for ExpandEnvironmentStrings(), so instead I deleted ExpandEnvironmentVariableStrings() and replaced its existing usages with wil::ExpandEnvironmentStringsW(). I then used wil::ExpandEnvironmentStringsW() when resolving the icon path as well.

Validation steps performed

Manual testing by taking a default profiles.json file and changing the '"icon" value for one profile, with empty string and with strings containing %ProgramFiles% at the start.

PR Checklist

…on" settings - fixes bugs 1468, 1867

First, I tried reusing the existing ExpandEnvironmentVariableStrings()
helper in TerminalApp/CascadiaSettings.cpp, but then I realized that
WIL already provides its own wrapper for ExpandEnvironmentStrings(),
so instead I deleted ExpandEnvironmentVariableStrings() and replaced
its usages with wil::ExpandEnvironmentStringsW().

I then used wil::ExpandEnvironmentStringsW() when resolving the
icon path as well. In addition, to allow empty strings,
I made changes to treat empty strings for "icon" the same
as JSON `null` or not setting the property at all.
Copy link
Contributor

@DHowett-MSFT DHowett-MSFT left a comment

Choose a reason for hiding this comment

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

This is awesome. Just a couple minor questions and suggestions.

As for [1]: should we just knock it out for background image as well? That suggests that functions that return paths out of Profile should just pre-expand them (but never store them expanded, because reserialization would be depressing), except with the notable (and commentable!) exception of command line, which we can just leave up to CreateProcess

src/cascadia/TerminalApp/App.cpp Show resolved Hide resolved
auto path = profile.GetIconPath();
winrt::hstring iconPath{ path };
std::wstring path{ profile.GetIconPath() };
std::wstring envExpandedPath{ wil::ExpandEnvironmentStringsW<std::wstring>(path.data()) };
Copy link
Contributor

Choose a reason for hiding this comment

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

should we expand these here or in GetIconPath? Either way, we'll need to issue a settings reload when we get the window message indicating that the environment changed (#1125), but perhaps it'll make easier the comment I'm about to leave at the end of the review [1]

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I could go either way on this. Initially I had the expansion done in Profile.GetIconPath(); I changed it because I felt it would be inconsistent with other code in Profile. But see my reply to your point [1].

src/cascadia/TerminalApp/App.cpp Outdated Show resolved Hide resolved
src/cascadia/TerminalApp/CascadiaSettings.cpp Outdated Show resolved Hide resolved
src/cascadia/TerminalApp/CascadiaSettings.cpp Show resolved Hide resolved
Copy link
Contributor

@DHowett-MSFT DHowett-MSFT left a comment

Choose a reason for hiding this comment

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

(i meant to mark "request changes")

@ghost ghost added Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something and removed Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something labels Jul 20, 2019
Copy link
Contributor Author

@metathinker metathinker left a comment

Choose a reason for hiding this comment

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

As for [1]: should we just knock it out for background image as well? That suggests that functions that return paths out of Profile should just pre-expand them (but never store them expanded, because reserialization would be depressing), except with the notable (and commentable!) exception of command line, which we can just leave up to CreateProcess

If we change to expand variables in all of Profile's file path strings other than commandLine, we'd also have to change some of the special handling for startingDirectory, which already expands variables as well. That might be a bigger change than would reasonably fit in a single PR. What do you think?

auto path = profile.GetIconPath();
winrt::hstring iconPath{ path };
std::wstring path{ profile.GetIconPath() };
std::wstring envExpandedPath{ wil::ExpandEnvironmentStringsW<std::wstring>(path.data()) };
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I could go either way on this. Initially I had the expansion done in Profile.GetIconPath(); I changed it because I felt it would be inconsistent with other code in Profile. But see my reply to your point [1].

src/cascadia/TerminalApp/CascadiaSettings.cpp Outdated Show resolved Hide resolved
src/cascadia/TerminalApp/CascadiaSettings.cpp Show resolved Hide resolved
@@ -20,122 +20,4 @@
<longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware>
</windowsSettings>
</application>
<!--
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not sure why, but the bcz build itself seems to keep changing this file. Should I leave the changes? They seem similar to changes that were manually done in PR #2043 so I hope they're not bad.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, I think it's fine. And that one is already merged. @DHowett-MSFT would be able to confirm.

Copy link
Member

Choose a reason for hiding this comment

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

Oh shiz, that's actually a really good catch. I'll file a task to fix this the right way. Basically #2043 needs to get applied to these tests too.

Copy link
Member

Choose a reason for hiding this comment

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

(for know this is fine)

Copy link
Member

@miniksa miniksa left a comment

Choose a reason for hiding this comment

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

:shipit:

src/cascadia/TerminalApp/App.cpp Outdated Show resolved Hide resolved
src/cascadia/TerminalApp/CascadiaSettings.cpp Show resolved Hide resolved
@@ -20,122 +20,4 @@
<longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware>
</windowsSettings>
</application>
<!--
Copy link
Member

Choose a reason for hiding this comment

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

Yeah, I think it's fine. And that one is already merged. @DHowett-MSFT would be able to confirm.

Copy link
Member

@miniksa miniksa left a comment

Choose a reason for hiding this comment

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

I guess I left comments and should request changes, not approve.

@ghost ghost added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Jul 24, 2019
@miniksa
Copy link
Member

miniksa commented Jul 24, 2019

I very much want to start using this wil::ExpandEnvironmentStrings thing elsewhere like in Entrypoints.cpp as well, but that's probably outside the scope of this particular fix.

@ghost ghost removed the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Jul 24, 2019
Copy link
Member

@zadjii-msft zadjii-msft left a comment

Choose a reason for hiding this comment

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

Looks great to me!

@metathinker
Copy link
Contributor Author

@DHowett-MSFT, please take another look.

Copy link
Contributor

@DHowett-MSFT DHowett-MSFT left a comment

Choose a reason for hiding this comment

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

Thanks!

@DHowett-MSFT DHowett-MSFT merged commit 66d46ed into microsoft:master Jul 25, 2019
mcpiroman pushed a commit to mcpiroman/terminal that referenced this pull request Jul 26, 2019
…icrosoft#1468, microsoft#1867 (microsoft#2050)

First, I tried reusing the existing ExpandEnvironmentVariableStrings()
helper in TerminalApp/CascadiaSettings.cpp, but then I realized that
WIL already provides its own wrapper for ExpandEnvironmentStrings(),
so instead I deleted ExpandEnvironmentVariableStrings() and replaced
its usages with wil::ExpandEnvironmentStringsW().

I then used wil::ExpandEnvironmentStringsW() when resolving the
icon path as well. In addition, to allow empty strings,
I made changes to treat empty strings for "icon" the same
as JSON `null` or not setting the property at all.

Co-Authored-By: Michael Niksa <[email protected]>
@ghost
Copy link

ghost commented Aug 3, 2019

🎉Windows Terminal Preview v0.3.2142.0 has been released which incorporates this pull request.:tada:

Handy links:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants