workbench.colorCostumizations deleted on remote connect

[oligu]

Versions (please complete the following information):

• OS: Windows / RaspiOS
• VS Code version 1.59.4
• Peacock Version v3.9.1

Describe the bug I use VSCode on Windows to access remote hosts over SSH running Raspberry Pi OS. Peacock is installed on the local VSCode. When I open the connection, the "workbench.colorCustomizations" settings in the *.code-workspace file get deleted.

To Reproduce

1. Have a local installation of VSCode with the peacock extension installed and remote connections enabled
2. Connect to a remote device over SSH
3. Create a workspace and apply a peacock color
4. Save the project and close the connection
5. Reconnect to the device and open the workspace
6. The color is not applied to the window and the "workbench.colorCustomizations" settings in the *.code-workspace are deleted

Expected behavior The color gets applied each time I connect to the workspace and the peacock setting do not change

Additional context Strange enough, the "peacock.color": setting does not get deleted

[johnpapa]

Thank you @oligu for creating this issue!

[johnpapa]

Can you share a repro video of this? I'm not following entirely and I do not have the ability to try this as I dont have the same setup as you

[MarcoKramer]

I am experiencing the same, but then with Windows and WSL (so VS Code in Windows opening a repo in WSL/Debian). When opening a Windows repo it does not happen. If I disable the Peacock extension it also does not happen, so I guess it's something in Peacock that does it.

[JacobHenner]

Also experiencing this issue - perhaps related to https://github.com/johnpapa/vscode-peacock/issues/480#issuecomment-971183705 / https://github.com/johnpapa/vscode-peacock/issues/480#issuecomment-971148980

I use Windows locally, connected to a remote Linux session over SSH. In a new project, peacock sets the following automatically:

{
    "workbench.colorCustomizations": {
        "activityBar.activeBackground": "#fbed80",
        "activityBar.background": "#fbed80",
        "activityBar.foreground": "#15202b",
        "activityBar.inactiveForeground": "#15202b99",
        "activityBarBadge.background": "#06b9a5",
        "activityBarBadge.foreground": "#15202b",
        "commandCenter.border": "#15202b99",
        "sash.hoverBorder": "#fbed80",
        "statusBar.background": "#f9e64f",
        "statusBar.foreground": "#15202b",
        "statusBarItem.hoverBackground": "#f7df1e",
        "statusBarItem.remoteBackground": "#f9e64f",
        "statusBarItem.remoteForeground": "#15202b",
        "titleBar.activeBackground": "#f9e64f",
        "titleBar.activeForeground": "#15202b",
        "titleBar.inactiveBackground": "#f9e64f99",
        "titleBar.inactiveForeground": "#15202b99"
    },
    "peacock.remoteColor": "#f9e64f"
}

When I disconnect and reconnect, these values are reset and the color changes. I speculate that the issue is that peacock only looks for peacock.color on startup/connection to the remote when deciding whether it should reset the configuration, instead of also considering the existence/value of peacock.remoteColor.

Edit: Setting peacock.color doesn't change the color of the remote window, but it does prevent the rest of the fields from being overwritten.

[JacobHenner]

I believe I've narrowed this down - it seems like vscode.workspace.getConfiguration() is failing to read configuration from the remote workspace's .vscode/settings.json configuration on startup, and is only able to read that value successfully sometimes afterwards. Perhaps Peacock is starting before the remote workspace is accessible, so getConfiguration() returns a value that leads Peacock to believe that no remoteColor is set (triggering surprise me to kick in), instead of blocking extension loading or configuration reads on the availability of configuration data from the remote workspace?

This can be tested by setting remoteColor at either the remote configuration level or the User level. Peacock will recognize those values on startup, but it will not recognize the remote Workspace remoteColor value.

[wraiford]

bump

[mig8447]

This is still reproducible on Peacock v4.2.2 VSCode 1.78.2, although not sure if it is a VSCode Issue or a Peacock one

[wraiford]

Did I breach some etiquette unbeknownst to me @willpower232 ? Why the thumbs down?

[Domiii]

This is still an issue... A fix would be very welcome, since it effectively breaks peacock for remote VSCode sessions (unless one is to apply some workarounds, where I keep forgetting what those are)

[Domiii]

Workaround 🥳

Just tested this and it works:

• By default, peacock will add peacock.color and workbench.colorCustomizations to settings.json (when you use the standard peacock commands to customize the colors).
• Manually adding peacock.remoteColor="whatever your peacock.color is" fixes this. colorCustomizations are not removed anymore.

[tommcc]

@Domiii can you clarify your workaround? Are you adding peacock.remoteColor to your user settings.json, or to the settings.json on the remote project?

For me, doing either for me doesn't actually change the outcome—the remote's color always changes after connecting.

[tommcc]

To follow up, the best compromise I got to with the current behavior is to turn off "Surprise me on startup". If auto surprise me is off, remote windows don't get their colors overwritten, and I just have to manually run "Surprise me" for new projects.

Setting a color when local/remote always sets color/remoteColor, respectively.