Statusbar color change in one window affects ALL open vscode windows

[gitenstuff]

Describe the bug
vim.statusBarColorControl": true

When editing a file the status bar turns red for insert mode and green for normal mode. The problem is that if you have multiple vscode windows opened, all of the statusbars change color. So, I could be normal mode in two code windows. In the first window, I enter insert mode. Status bar turns red ->ON BOTH WINDOWS<

If I disable the extension in one of the windows, then change mode in the other window, even then, the window with disabled extension changes color.

To Reproduce
Steps to reproduce the behavior:

set vim.statusBarColorControl": true
cd proj1; code .
cd proj2; code .
in both projects, open any file
now, both statusbars are green (--NORMAL--)
In proj1, enter insert mode
proj1>statusbar goes red, as expected
proj2>statusbar goes red (even though it is still in NORMAL MODE and should have remained green
Expected behavior
Color of every statusbar in every project window change colors independently.

Screenshots

Environment (please complete the following information):

Extension (VsCodeVim) version: 1.2
VSCode version: 1.96.2
OS: Alma Linux 9

[bavjackson]

if (currentColorCustomizations !== colorCustomizations) {
      void workbenchConfiguration.update('colorCustomizations', colorCustomizations, true);
}

Seems like this could be sorted by changing true to false/undefined (line 160, statusbar.ts), but I'm not sure if there was a specific reason for it being set this way to start with.

[gitenstuff]

@bavjackson

Go from normal to insert mode in window_1:
Window_1 debug output shows:

1 change(s) to /home/user/.config/Code/User/settings.json because undefined
2024-12-26 06:24:48.717 [info] /home/user/.config/Code/User/settings.json closed

Whiile window_2 debug output shows:

2024-12-26 06:24:49.244 [info] Configuration changed

What is the change in settings.json?

diff --git a/settings.json b/settings.json
index a7bfab6..c0bc7bf 100644
--- a/settings.json
+++ b/settings.json
@@ -86,9 +86,9 @@
   "diffEditor.useInlineViewWhenSpaceIsLimited": false,
   "workbench.colorTheme": "Tomorrow Night Blue",
   "workbench.colorCustomizations": {
-    "statusBar.background": "#5f0000",
-    "statusBar.noFolderBackground": "#5f0000",
-    "statusBar.debuggingBackground": "#5f0000",
+    "statusBar.background": "#5f00af",
+    "statusBar.noFolderBackground": "#5f00af",
+    "statusBar.debuggingBackground": "#5f00af",
     "statusBar.foreground": "#ffffff",
     "statusBar.debuggingForeground": "#ffffff"
   },

>>Notice<< that when switching from one editing tab to another within the same window triggers the change in settings.json as well.

Seems to me that the mechanism the extension is using to update the statusbar color is to change the worbench.color customizations setting. VsCode in both windows picks up the settings change and then changes the status bar accordingly.

In effect, the workbench.color settings are being used as global state variable and since vscode is, presumably, polling for changes (watching) in the settings.json, all code windows would react.

A possible work-around might be to record these statusbar color state changes in the workspace settings.json instead of the global ~/.config/Code/User/settings.json. Then the effect would be limited to multiple windows opened within the same workspace system-wide. But that's a sub-par solution, and kinda hacky.

A real solution would be to use the Code api's to directly change the statusbar color, however I don't know if that is even possible. I would assume the developer chose the route that he did because he could not find a way to get it done with the api or that statusbar-color is simply not exposed by the api.

If the api does not expose statusbar color -meaning the only way to change statusbar-color is to twiggle the settings.json entries- then there is no real work-around or fix. In other words, you get one status-bar color at a time for ALL windows.

I haven't the time right now to explore code-api-status-bar color, but I'm pretty sure I've identified the root of the problem.

[gitenstuff]

@bavjackson

If you do as you propose, then the statusbar will not change in any of the windows. But we might consider if we could manage a local state variable that keeps track of if we are expecting a change in OUR window and including it in the if-condition.

Drawback there is that changing the statusbar color from outside the extension -some-other extension, or core vscode behaviour will/might be missed. It's better than nothing though.

if (currentColorCustomizations !== colorCustomizations) {
void workbenchConfiguration.update('colorCustomizations', colorCustomizations, true);
}

Seems like this could be sorted by changing true to false/undefined (line 160, statusbar.ts), but I'm not sure if there was a specific reason for it being set this way to start with.

[gitenstuff]

@bavjackson
Nevermind last comment. That line you reference is where the decision is made to change the statusbar color. The problem occurs after the setting has been changed. And if it isn't changed, I don't think the statusbar color would change at all, as I had said before.

[bavjackson]

@gitenstuff the boolean as the 3rd param in workbenchConfig.update determines whether the change is in the local workspace vs global user settings (docs here) I've tried changing that locally to false and it seems to work fine, keeps the settings local to the current window vs the overall user config. I'm just not sure why that decision was made to have it global in the first place.

The vscode api has a few limitations as to what it lets an extension do directly. Changing statusbar/statusbar item background colour seems to be one area where it's particularly locked down, partly for accessibility reasons as an extensions colours could be unreadable against a particular theme and warnings/errors need to be visible to the end user. Especially if various types of eye imparements come into play. Changing it on a workspace rather than global user level is probably the best that's possible without a major change to the extension api from microsoft.

[gitenstuff]

@bavjackson
Thanks! I should have looked at workbenchConfig.update more closely.

I've tried changing that locally to false and it seems to work fine,
Can you describe what, exactly, you did to test that?

I wonder if the git history for that line ever had the parameter set to false? That might lead to an idea about how come it was set to true by the developer...

In any regard, it looks like there is a fix. I've never submitted a PR for something like this before - I'm not sure that I am prepared to do it anytime soon, but if I were to code this straight-forward fix, what would I need to do in order to conform to PR and project contrib etiquette as far as supplying code for automated testing -if that would even be required.