Selection, highlighting and search colors conflict with each other

[monk-time]

• VSCode Version: Code 1.16.0 (787b31c, 2017-09-06T16:27:49.891Z)
• OS Version: Windows_NT x64 6.1.7601
• Extensions:

Extension	Author (truncated)	Version
intellij-idea-keybindings	k--	0.2.13
selectline-statusbar	tom	0.0.2

Reproduces without extensions: Yes

---

Background colors for the editor selection, word highlighting and search matches all conflict with each other in an unexpected way, which seems to be caused by multiple bugs in color priorities and mixing rules.

Text selection color is not restored after searching

The following rules set all three highlighting colors to #FF0000 and text selection to #00FF00 on a black background.

"workbench.colorCustomizations": {
    "editor.background": "#000000",
    "editor.foreground": "#FFFFFF",
    "editor.lineHighlightBackground": "#000000",
    "editor.selectionHighlightBackground": "#FF0000",
    "editor.findMatchBackground": "#FF0000",
    "editor.findMatchHighlightBackground": "#FF0000",
    "editor.findRangeHighlightBackground": "#000000",
    "editor.selectionBackground": "#00FF00",
    "editor.inactiveSelectionBackground": "#00FF00"
}

Normal selection works as expected:

Case 1: put the cursor at the start of the second line and press Ctrl+D ("Add Selection To Next Find Match") three times, none of the three selections become partially or completely green. Since there's no search bar opened, I expect the text selection color to apply here. Pressing Shift+Left to shrink selection re-applies the selection color:

Changing both editor.findMatch* settings to different colors and repeating the steps above doesn't change anything, selected regions are still red.

This is even more confusing if you use the search bar, because multiple cursors for Ctrl+D don't get drawn or animated in that mode (case 2).

Case 3: put the cursor at the start of the file, press Ctrl+F, type "aaa", press Esc (here I expect green color to be applied to the selection, but it doesn't), press Shift+Left. Only then the selection color appears.

This looks a bit different if editor.findMatchBackground is set to #0000FF, but the green color is still not applied after hitting Esc:

Case 4: while "aaa" is still the last searched term, put the cursor at the start of the file, press F3 ("Find Next") and then Esc. This is the only way I could force the green selection color to appear right after using the search:

Case 5: there's something weird going on with the first match. If you repeat the steps from the case above but press F3 several times, after hitting Esc the color of the first match disappears completely:

---

Expected behavior for all cases above: editor.selectionBackground color should be applied to all selected regions when the selection is made without opening the search bar or after it was closed.

Inconsistent blending of findMatch* colors

The following rules set text selection to #303030 (to affect other colors as little as possible), regions with the same content as selection to #FF0000, and current/other search matches to #0000FF/#00FF00.

"workbench.colorCustomizations": {
    "editor.background": "#000000",
    "editor.foreground": "#FFFFFF",
    "editor.lineHighlightBackground": "#000000",
    "editor.selectionHighlightBackground": "#FF0000",
    "editor.findMatchBackground": "#0000FF",
    "editor.findMatchHighlightBackground": "#00FF00",
    "editor.findRangeHighlightBackground": "#000000",
    "editor.selectionBackground": "#303030",
    "editor.inactiveSelectionBackground": "#303030"
}

In this setup, depending on how and where the search bar is opened, the highlighting of matches changes in an unpredictable and seemingly random way.

Case 6: remove the last searched term from the search bar, put the cursor at the start of the file, press Ctrl+F, type "aaa", press Enter or F3 several times. Both editor.findMatch* are blended with alpha 50% with the red editor.selectionHighlightBackground .

Case 7: while "aaa" is the last searched term, put the cursor at the start of the file, press Ctrl+F, then F3 or Enter several times. Unblended green editor.findMatchHighlightBackground appears until you select search matches, then it changes to blended colors from the previous case.

Case 8: while "aaa" is the last searched term, put the cursor at the start of the file and press F3 several times (same as in case 5). All colors are unblended, but editor.findMatch* apply only to the first match.

Case 9: put the cursor at the start of the second line and press F3 several times. None of editor.findMatch* apply at all.

---

In all four cases the expected behavior would be to apply editor.findMatch* correctly no matter how the search was triggered. Also, blending is undocumented and very unexpected: editor.selection* and editor.findMatch* pairs seem to be designed to mirror each other, with each active only in their respective editor mode. But only editor.selectionHighlightBackground is blended with one or both colors from the other pair, and there's no way to influence or override this. Since there are two pairs, blending seems completely unnecessary to me.

[Piping]

add support to change the foreground text color when the text is selected?
Like the setting here in VS Link

[monk-time]

@Piping, that is a different issue. The foreground text is irrelevant here, but that issue was opened by people who like me noticed the low contrast for selected search matches. There are several settings introduced since then, but here I override all of them and still see many irregularities.

The main problems here are that (1) the selection color is not applied when you close the search bar or use Ctrl+D without opening it, (2) editor.findMatch* colors are bugged and (3) blended with another color even when all the relevant colors are provided by the user.

[monk-time]

But thanks for that link, I have found a similar issue #11354. Should I move this post there? That one seems to be more concerned with simplifying the design of configuring selection colors in general, but here I point out the small bugs that cause the current design to work inconsistently.

[alexdima]

@monk-time the root cause here is that all these decorations are rendered on top of each other, because they can all be active at the same time. In the editor "painting" code all these decorations are rendered, but depending on the arbitrary order in which decorations are added to the editor, they will be overimposed.

By using fully opaque colors the decorations end up "hiding" each other. Would it work for you to add a bit of transparency to your decoration colors? Or would you rather expect that we somehow mix those colors when they are overimposed (unclear how?) . e.g.:

"workbench.colorCustomizations": {
    "editor.background": "#000000",
    "editor.foreground": "#FFFFFF",
    "editor.lineHighlightBackground": "#000000",
    "editor.selectionHighlightBackground": "#FF000088",
    "editor.findMatchBackground": "#0000FF88",
    "editor.findMatchHighlightBackground": "#00FF0088",
    "editor.findRangeHighlightBackground": "#00000088",
    "editor.selectionBackground": "#30303088",
    "editor.inactiveSelectionBackground": "#30303088"
}

[monk-time]

@alexandrudima, I understand that decorations are rendered on top of each other, what my post is trying to show is that there are cases where the correct color doesn't get drawn after closing the search bar (selectionBg in cases 1-5) or if the search is triggered in a specific way (cases 6-9). Lots of small bugs here.

Adding transparency is a whole other can of worms that I don't want to open here, because it requires a calculator to reverse-mix multiple colors to figure out how to make the editor show the colors I need, and the above-mentioned bugs turn this into a very frustrating task. This is why I specify only solid colors, but then unexpectedly the editor mixes some of them (selectionHighlightBackground but not selectionBackground) sometimes (cases 6-7) but not always (cases 8-9).

If I don't use transparent colors in my theme, the editor should not mix any of them at all. Mixing should be enabled only for those colors that are either not solid or not specified by the user.

[monk-time]

@alexandrudima, was my feedback helpful? I guess I spent too much time writing this bug report so now I have become way too emotionally invested in its fate, even though it's a minor issue. I hope it didn't sound rude when I referred to what I assumed are bugs as such, if the content of my OP is intended behavior you can close this issue.

[alexdima]

@monk-time I appreciate the fine and detailed steps and your thoughts.

To attempt to improve this, we need a new concept which we currently don't have, that of "recency".

When the view code needs to paint decorations, it doesn't know which one should go on top of which one. The current tie-breaker is "alphabetical" on some internal class names.

In a way, this is as-designed. But I agree, that this could be better if we would have the concept of "recency" in the decorations and use that as a tie-breaker when two decorations need to be painted at the same spot.

[mliq]

My issue is:

1. search all files using searchViewlet
2. open one of the resulting files and do a separate search in the findWidget
3. Results of both searches have the same highlight color - this is not ideal, but not a huge issue. The bothersome issue is: anything that is highlighted by both the original searchViewlet search and the new findWidget search does not get the editor.findMatchBackground color highlight when selected.

I would think that the editor.findMatchBackground highlight should always override any other highlight and wouldn't be a major overhaul to fix? Should this be a separate issue/ticket?

[Chillee]

In VSCodeVim's case, we need to create a fake cursor by using a decoration. However, in certain scenarios, the cursor ends up disappearing due to the fact that it's getting overridden by the selection decoration.

I don't know what a good solution would be, but just wanted to chime in and say that some kind of solution for resolving conflicts in decorations would be nice.

[chibicode]

This (and the lack of support for adjusting foreground color: #36490) seems to be causing headaches for some theme designers:

sdras/night-owl-vscode-theme#90

I found it very hard to make a theme that both looked good and had enough contrast in the selections that made them easily recognizable.

Unfortunately, VSCode doesn't have the ability to inverse the text color or specifically adjust the text color in conjunction with selections.

[mattaningram]

This issue is almost making me switch back to Atom. None of the themes I find have any significant difference between the auto highlights and manual text selection, and for some reason I can't get the auto highlight styling to change no matter what I put in my custom settings.

Can VSCode emulate how Atom handles these effects?

[glen-84]

@alexandrudima,

Instead of a "recency" concept, couldn't you also just have a hard-coded priority order?

1. Decorations added by extensions (f.e. VSCodeVim)
   • Could use recency if there are multiple decorations set by extensions.
2. User selection (should always be [2nd from] the top)
3. Find match
4. Find match highlight

Am I missing any? Wouldn't that solve most of the issues?

My main issue is not being able to see a selection inside of a find match:

(possibly related to #43928)

@monk-time,

Your issue description is very thorough and well-written. Nicely done.

[mkanet]

Are there any workarounds for this? Not being able to see my selection color on a find matched text makes it hard to know for sure if I've selected the text or not. I'm not sure how other people deal with this.

[123dev]

Here's how I deal with it.
I make Find background totally transparent, but highlight a border.
Same with keywords.
This way selection background color remains intact.

Here are my settings, which works well for Dark+ theme, you might want to change the colors for a light theme.

"workbench.colorCustomizations": {
	// Totally Transparent
	"editor.selectionHighlightBackground": "#ffffff00",
	"editor.findMatchHighlightBackground": "#ffffff00",
	// Borders
	"editor.findMatchBorder": "#ffff00",
	"editor.findMatchHighlightBorder": "#ff0000",
	"editor.selectionHighlightBorder": "#ffffff",
	"editor.lineHighlightBorder": "#272727",
	// Selection
	"editor.selectionBackground": "#771835",
	"editor.wordHighlightBackground": "#771835",
	// Misc
	"editorCursor.foreground": "#00ff00",
	"editor.lineHighlightBackground": "#181818",
	"editor.findMatchBackground": "#000000",
	// Debugger
	"statusBar.debuggingBackground": "#410d18",
	"statusBar.debuggingForeground": "#dddddd"
}

[ygoe]

Is this going to be fixed one day? I have these parts in my settings json:

    "workbench.colorCustomizations": {
        "editor.wordHighlightBackground": "#e8e8d8",
        "editor.selectionHighlightBackground": "#d8ffd8"
    },

I just wanted to make those two colours more pleasant. But as soon as they appear in the config, they both overpaint each other and the selection background. I can also add the selection background to my config but it'll still be overpainted by the others. It seems like those three colours are painted in the exact wrong order if one is defined in the user config. The default is fine but these colours cannot be changed without breaking the paint order.

Order of definition in the config json doesn't matter, it won't improve things.

This is a major annoyance because the default colours are not looking good and the good colours are hiding essential parts of the editing experience. I wouldn't expect such a big issue in the core component to remain unnoticed for so long for an actively maintained project.

I'd suggest to keep the default paint order unchanged, it's all good. But if the user alters the colours, these colours should just be used, without affecting the paint order. That seems to be the real bug here. Colour overriding affects paint order which should not be the case.

[ygoe]

BTW, I wouldn't call this a feature request but a real bug. One of the supported features is to change references colours (to make it more recognisable/legible). A second supported feature is selected word highlighting with another colour. An essential feature of any editor is to visually indicate selected text. The supported feature breaks both another supported feature and the essential feature completely, making the editor almost unusable in this moment. And selecting text happens a lot! I've noticed I made selection mistakes a lot which never happens when I can actually see the selection. So we have a complete failure of essential functionality, 100% reproducible, happening several times per minute every day. What more does it take for a bug?! I've seen less important editor behaviour fixed within days, so what's gone wrong with this one? Somebody needs to be made aware of it?

[tobia]

I agree, the order of importance should be:

1. show the current selection—right now this is not number 1. and therefore breaks the editor;
2. show the current search results—if this can be combined with selection, eg. one is a background and the other is a border (which is true in most themes) so be it, otherwise hiding or overriding the search result highlighting when you select part of it is an acceptable compromise—not the other way around, which is the current behaviour;
3. finally, highlight other occurrences of the word under cursor—this should be a low-priority visual help.

As it stands right now, the order is 2. 1. 3. which, as mentioned, breaks the editor completely whenever there exist a "current search", which is a lot of the times for many editing jobs.

---

Edit: I will leave my comment above, but I might have misunderstood something, because I managed to fix my issue by just adding the following:

"editor.findMatchBackground": "#0000",

(four zeros = RGBA transparent)

[ygoe]

@kieferrm Please retriage or forward to somebody more appropriate. This is not a feature request but a bug (and a very annoying one IMHO), and like this, nobody is aware of this issue.

[jpduckwo]

This issue is very annoying - worst part of vscode right now imho...
So many functions highlight text:

• folder based search
• file based search
• cursor on a variable
• highlighted text
• multi cursor
• hover over
• symbol highlight
• word highlight
• active line

All these mix together to a distracting mess that it get confusing what you've got highlighted . I've tried all the top dark themes, none of them handle it well. Not sure what the solution is, maybe if you could style all the hints as underline only so that text highlighting stands out?

[jpduckwo]

    "workbench.colorCustomizations": {
        "editor.findMatchBackground": "#000000",
        "editor.findMatchBorder": "#ffff00cc",
        "editor.findMatchHighlightBackground": "#ffffff00",
        "editor.findMatchHighlightBorder": "#ff000080",
        "editor.lineHighlightBackground": "#ffffff00",
        "editor.lineHighlightBorder": "#ffffff00",
        "editor.selectionBackground": "#aa00ff",
        "editor.selectionHighlightBackground": "#ffffff00",
        "editor.selectionHighlightBorder": "#ffffff44",
        "editor.wordHighlightBackground": "#ffffff00",
        "editor.wordHighlightBorder": "#ffffff44",
        "editorCursor.foreground": "#00ff00",
        "statusBar.debuggingBackground": "#410d18",
        "statusBar.debuggingForeground": "#dddddd",
        "editorBracketMatch.background": "#ffffff00",
        "editorBracketMatch.border": "#ffffff00",
        "editor.symbolHighlightBackground": "#ffffff00",
        "editor.wordHighlightStrongBackground": "#ffffff00"
    }

My best attempt - use with a dark theme. This turns off most background highlighting and uses faint borders when important. I also turned off background on bracket matching - thats another one to add the confusion. (I'm using Bracket Pair Colorization: true for that anyway)

[ygoe]

Yay, now we have bracket pair colorisation! I'm pretty sure that it will break text selection if I dare to choose other colours than the predefined ones. This is very much frustrating. Nobody will ever fix the most essential bugs in the most essential part of this application. Nobody in power will even ever read these bug reports! At least I have no evidence for it.

[wsuszycki]

The issue still exists after last update. I tried to contact with VS Code team on facebook but they sent me to https://morioh.com/topic/vscode. I posted there a week ago but no one replied. I asked again on facebook but there is no answer.
On the VS Code page link "Support" opens sign in to Microsoft Account. But it is also a dead end because they want me to buy some technical support plan.
Does anyone have any idea how to successfully report this bug to VS Code developers?

[ygoe]

When using the VS Code editor, I'm still flying completely blind for considerable amounts of time, especially when moving text around. I need to remember what I've selected from pressing the keys because it's not displayed! Every text editor on this planet does it correctly but not VS Code. Is anybody going to do something about this? Is anybody here? Product manager? QA? Customer satisfaction? All gone?! Should I start looking for alternatives to VS Code? I really question the competence of the people leading this project if the most essential and critical bugs are not adressed, even have the least possible priority with zero attention, while truckloads of other new stuff keep coming in. I'm wondering in what state the new things are if the existing ones are so broken.
@bpasero @jrieken @joaomoreno @mjbvz @alexdima @sandy081 @Tyriar @rebornix @aeschli @roblourens (Sorry for the mentioning spam. There's no "escalate to manager" function here so I went through the top contributors in hope of addressing someone who's still involved. Given others were so unsuccessful contacting anyone I found this a reasonable measure. Please let me know if I need to add more mentions.)

[aeschli]

@ygoe Did you look into customising the colors for your needs? Maybe there's already a theme on the marketplace that your like better? It's a difficult problem to find colors that all work together and are useful for everyone. We are extremely careful when making changes to our default themes as this can cause strong user reactions.

[ygoe]

@aeschli The problem is not the colours, it's how they're not applied and rendered correctly (or sanely). My colours are fine, but I don't get to see them because they overlay in the wrong paint order. In fact, any colours I customise are wrong, so a different theme won't help at all unless it doesn't touch those colours. Problem not solved.

[aeschli]

@ygoe Did you add an alpha value to the colors? That's important. Most highlight colors must not be opaque, see the color descriptions.

[Tyriar]

@ygoe please don't ping random people like this, you've done it multiple times here. Almost everyone you pinged has nothing to do with this and you end up wasting their time.

I really question the competence of the people leading this project if the most essential and critical bugs are not adressed, even have the least possible priority with zero attention, while truckloads of other new stuff keep coming in.

This doesn't look like a critical bug to me and it's one issue among thousands we have, this doesn't even show up in the top 10 pages. Just because we ship new features doesn't mean the project is 100% bug free, that's impossible.

[ygoe]

@aeschli That was a very good point indeed! I didn't have an alpha value for these two colours, they were fully opaque. As soon as I made them darker but also transparent, things look much better. Thank you for that hint! This solution should be more prominent to avoid this kind of trouble.

Re-reading some of the earlier comments, this also seems to be the problem for others. And the hint about transparent colours was even mentioned one time in a question, hard to discover. Then the proposed workarounds used borders instead of backgrounds, completely distracting from the problem to solve. I still believe that the paint order (or z-index) is not correct (or appropriate), but adding transparency diminishes the effect of wrong colour mixing to be unnoticeable.

I'm still confused about the different word highlighting when putting the cursor in a word for each file type (JS uses wordHighlightBackground for most symbols, SCSS uses wordHighlightBackground for every single word whatever it is, HTML uses wordHighlightBackground only for tags, but JSON uses selectionHighlightBackground for every key or value including the quotation marks) but that's another topic.

@Tyriar Yes, what I've done is bad and I apologise for wasting a bit of your time. The thing is, there was no solution to this issue and it made the editor unusable in very common situations. Nobody pointed to potential issues with opaque colours before, so I guess it's not obvious for normal users. Transparent colours are also harder to control, you avoid it if you can.

This issue may not have many reactions (only half as much as the highest reacted-on issue, according to the numbers, still impressive to me). Probably because colour customisation isn't all that popular. You have the telemetry to prove me wrong. I'm using several different editors and need to align their colours somehow to not be completely lost here.

BTW, that issues list has an interesting sorting. All issues, sorted by most +1 reactions, the highest has 60 reactions. Limited to bugs (so less issues), same sorting, the highest has 314 reactions. Where was that one before?! I'd call that broken. 🤷‍♀️

[wsuszycki]

Adding an alpha value it's quite good solution but it's still workaround (much better than nothing). Thanks for suggestion!
A code snippet for anyone who is looking for a quick solution:

regular (opaque) color definition:
"editor.symbolHighlightBackground": "#007070",

alpha color definition:
"editor.symbolHighlightBackground": "#00707099",

where 99 is alpha value (ff - fully opaque, 00 - fully transparent)

[samajudia]

Please try to reduce transparency of other highlight (like it has to be more transparent than selectionword )