Controlling the background color of the active tab in an unfocused editor group

[dmolin]

It's currently not possible to set the background color of the active tab in un unfocused editor group.
With this PR we can now control the background color for the active tab in an unfocused editor group through the "tab.unfocusedActiveBackground" setting (under ""workbench.colorCustomizations").

[msftclas]

All CLA requirements met.

[bpasero]

This is a good start but unfortunately the tab background color is a bit special. See the usages of TAB_ACTIVE_BACKGROUND in the source code to understand why. We will have to adjust these places for the unfocused group as well I think.

[dmolin]

Thanks for the feedback @bpasero, highly appreciated, but I'm not sure I understand the extent of it. The only usages I see of TAB_ACTIVE_BACKGROUND are in the file where I made my changes. I see it used in dragging/dropping the tabs (something that I see working just fine with my change) and those places are not affected by the color of the active tab when unfocused (since the tab is supposed to be focused while dragging).

There's a place in tabsTitleControl.ts where "gradients" are reset when hovering on the tabs (active and inactive ones) but I don't think that's relevant, since the new setting is only supposed to determine the color of an "unfocused" active tab...

[bpasero]

@dmolin this applies when the tabs are configured to shrink (as you can see from the tab.sizing-shrink CSS rule via the setting "workbench.editor.tabSizing": "shrink") so I would think this also applies to your new color. Can you check?

[dmolin]

@bpasero Yeah you're right!
I had to fight a bit with it (the unfocused style was overriding the focused one) but then I found what the issue was and fixed it: The current style for the active tab background was not taking into account the tab container state (.active vs .inactive).
I added it to the selector and then I added the style for the unfocused (.inactive) container group. Everything seems to work perfectly (I tested it with both fit and shrink tab modes).

In the screenshot you can see how it looks in shrink mode, so I now have full control not only of the borders but also of the background of the active tab in an unfocused editor group:

I just pushed my changes. 😄

[dmolin]

@bpasero I made the last few tweaks and tested it. Ready for review.

[bpasero]

@dmolin should I do a final review, I think I can merge this today

[dmolin]

@bpasero yes, go for it 👍

[bpasero]

@dmolin is there a reason you chose to use .editor-group-container${hasFocus ? '.active' : ''} in the one case for hover and .editor-group-container${hasFocus ? '.active' : ':not(.active)'} in the other?

[dmolin]

@dmolin is there a reason you chose to use .editor-group-container${hasFocus ? '.active' : ''} in the one case for hover and .editor-group-container${hasFocus ? '.active' : ':not(.active)'} in the other?

I thought about adding :not(.active) also for the tabHover; Keep in mind, that code was alreay there before and was not using it. My concern is if that was made on purpose (so, better leave it as it was) or if it is something we can touch and improve on.. I went with being conservative since I'm not sure of the full extent of the possible side effect if adding ":not(.active)" there.

Tbh, I tested it with ":not(.active)" and it seemed to work just fine but, again, I'm not super sure if adding the more specific selector might have impacts on something else...

[bpasero]

Ok thanks I will change and probably align.

[dmolin]

@bpasero as you prefer. If you want I can make the change in a second, just let me know 😄

[bpasero]

@dmolin thanks, I merged it in.