$Host.PrivateData colors are completely broken in PowerShell 7.2

[Jaykul]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.
• Refer to the FAQ.
• Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

$PSStyle has completely broken the PrivateData colors. Setting them no longer changes anything.

Expected behavior

The colors on `$Host.PrivateData` should affect the output

Actual behavior

Changes to `$Host.PrivateData` don't do anything anymore

Error details

No response

Environment data

Name                           Value
----                           -----
PSVersion                      7.2.0
PSEdition                      Core
GitCommitId                    7.2.0
OS                             Microsoft Windows 10.0.22000
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visuals

This is what I expected:

[iSazonov]

/cc @SteveL-MSFT

[iSazonov]

$Host.PrivateData works if there is no virtual terminal or it is disabled.

[237dmitry]

Setting them no longer changes anything.

If I change $PSStyle.Progress.View to Classic then the progress colors are from $Host.PrivateData.Progress*

[dwtaber]

Hm. Error output obeys $Host.PrivateData.ErrorForegroundColor but not $Host.PrivateData.ErrorBackgroundColor for me, and only when $ErrorView = ConciseView. For any other value of $ErrorView, no coloration is applied.

Meanwhile, the Get-Error cmdlet applies $PSStyle.Formatting.Error coloration to the value of the returned object's Exception.Message property, as well as to the position-marking tildes of InvocationInfo.PositionMessage

[Jaykul]

So WITH NO NOTICE a bunch of code was broken that customized error and verbose output colors, and there is now no way to customize them in a compatible fashion, except to feature-sniff for types/versions and do it both ways.

I raised this MONTHS AGO as a REGRESSION BUG and I feel like it was completely brushed off and basically ignored.

What is going on with prioritization of development over there?!?

[SteveL-MSFT]

@dwtaber Error for classic view was a bug that was fixed via #17705

@Jaykul the WGs are working through issues, but haven't gotten to this one. I would propose to have a new $PSStyle.Formatting.UsePrivateDataColors set to $true by default which would have the old stream output use the old settings. We could automatically flip this to $false if any of the new formatting colors are set.

[Jaykul]

This did not (and does not) need to be one or the other. The new thing could have been implemented on top of the old. If you implement it as automatic switching, you risk total confusion, when all the colors change when someone meant to change only one...

Perhaps the more helpful thing would be to use the new $PSStyle but update it automatically when the PrivateData values are set. That is, treat PrivateData as a [ConsoleColor] limited setter for $PSStyle.Formatting.

So if something runs: $Host.PrivateData.ErrorForeground = "Red" then in addition to updating PrivateData, you could also set $PSStyle.Formatting.Error += $PSStyle.Foreground.Red

Or if they run $Host.PrivateData.ErrorForeground = "Black"; $Host.PrivateData.ErrorBackground = "Red" you could also set $PSStyle.Formatting.Error = $PSStyle.Foreground.Black + $PSStyle.Background.Red

Although right now, I'm not sure if the current formatting supports setting background colors. It seems broken to me.

[SteveL-MSFT]

@Jaykul that is also an option. The only problem is if then the user updates $PSStyle, it would not be possible to reflect that back into PrivateData unless they happen to use one of the 8 colors only. It might just be something that gets documented and could be ok.

[SteveL-MSFT]

Actually, there's a problem with your proposal. $Host.PrivateData is managed by the host (ConsoleHost, EditorServices, etc...), so every host would have to adopt that pattern. PrivateData is just a PSObject so a host can have whatever they want in there. The colors are just a de facto convention.

[Jaykul]

I think going one way would probably be good enough. I mean, I have code for converting from 16bit colors to 16 colors.

[Jaykul]

Actually, there's a problem with your proposal. $Host.PrivateData is managed by the host (ConsoleHost, EditorServices, etc...), so every host would have to adopt that pattern. PrivateData is just a PSObject so a host can have whatever they want in there. The colors are just a de facto convention.

So what you're saying is that the HOST is still trying to set the colors, but the engine is injecting escape sequences into the text that override the host's settings?

[SteveL-MSFT]

Write-Error, Write-Verbose, etc... are host callbacks. It's up to the host to decide how to display them. Here's the relevant section for ConsoleHost:

PowerShell/src/Microsoft.PowerShell.ConsoleHost/host/msh/ConsoleHostUserInterface.cs

Lines 1395 to 1402 in edac193

	if (SupportsVirtualTerminal)
	{
	WriteLine(value);
	}
	else
	{
	WriteLine(ErrorForegroundColor, ErrorBackgroundColor, value);
	}

. Currently, if VT is supported, it goes the VT route and by-passes the older code path that relies on [Console] APIs that accept [ConsoleColor] and overrides the color codes in the string (the string value still contains them).

So in the end, it's up to the host to decide what to do. This was an unfortunate design choice early on.

[Jaykul]

So, bottom line: you added a new, non-host way of injecting virtual terminal escape sequences for the same purposes that already existed in the host, and then changed the default host so that if it thinks it's running in a terminal that supports escape sequences ... it just ignores it's own settings.

Is that right? Is backward compatibility just out the window forever?

[SteveL-MSFT]

I've proposed a solution due to the limitations of the existing design. You had a different proposal which seemed good at first until I looked into it and it's not feasible. If you have an alternate proposal, let's discuss it.

[Jaykul]

I'm frustrated, but I don't know how I didn't understand that you'd deliberately deprecated PrivateData. Honestly, I don't think there's any point in putting a switch in. It would basically be the same as setting $ENV:TERM = "dumb" right?

Writing a warning that they're deprecated when someone sets those properties (in a host that SupportsVirtualTerminal?) would be nice, so people can be reminded those things are now useless ... but unless we can do that, I think we might as well just close this "as designed". 😣

[theJasonHelmick]

The Interactive WG has reviewed this long standing issue. We don't think that PrivateData can be linked well to PSStyle to remove a poor affect from PrivateData. We think the current behavior of PSStyle was the intended design change, however we want to review this committee before closing this issue.

[theJasonHelmick]

Thank you to all that commented on this issue.  The PowerShell committee has reviewed and concurs with the Interactive WG that this feature is by designed.  We will investigate in the future to emit a depreciation warning if any private data is changed.

[microsoft-github-policy-service]

This issue has not had any activity in 6 months, if there is no further activity in 7 days, the issue will be closed automatically.

Activity in this case refers only to comments on the issue. If the issue is closed and you are the author, you can re-open the issue using the button below. Please add more information to be considered during retriage. If you are not the author but the issue is impacting you after it has been closed, please submit a new issue with updated details and a link to this issue and the original.