I make the text bold for better readability as the normal colors are rather faint.

See also:

• resource:///chrome/devtools/skin/
• resource:///chrome/devtools/skin/light-theme.css

• resource:///chrome/devtools/content/
• resource:///chrome/devtools/content/shared/sourceeditor/codemirror/lib/codemirror.css

.cm-s-mozilla.CodeMirror-focused .CodeMirror-selected { /* selected text (focused) */
  background: rgb(185, 215, 253);
}

.cm-s-mozilla .CodeMirror-selected { /* selected text (unfocused) */
  background: rgb(210, 210, 210);
}

.cm-s-mozilla .CodeMirror-activeline-background { /* selected color with alpha */
  background: rgba(185, 215, 253, .35);
}

Thanks. I have fonts set = bold, too (in another rule). That doesn't help much if the syntax color of something happens to be somewhat near the color of the selected text background.

You're using the light theme, which may? make selected text background color work a bit better? I have to use a dark theme.

I don't think the background you show:  .cm-s-mozilla.CodeMirror-focused .CodeMirror-selected { /* selected text (focused) */
 background: rgb(185, 215, 253); }

is actually placing the BG color BELOW the selected text, in this case.

Why? Because the very lite yellow selected text color I use w/ 0.6 alpha value, significantly dulls / fades almost all the syntax colors in Style Editor. If it was really underneath the dark text, it wouldn't reduce fairly dark colors' contrast.

A syntax color like med. gray / dark beige is barely visible - even using 0.6 alpha in rgba for pale yellow selected text BG. (affecting Style Editor).

The short workaround is use a very low rgba alpha value (.2) on the BG color.

It's no longer light yell (on black body BG color), but it's visible enough to easily see where highlighting begins / ends, and it hardly affects the color of selected code.

As for the question, "does Code Mirror (in Style Editor) have a hidden option to change foreground text color (to something contrasting) when selecting text (using what they call "background" color)? I think I answered it myself.

No, I don't think it does - not as it's configured in Fx devtools. Mozilla decided on some things to leave out, or even picking colors for you. There are several bugs, asking devs to change specific colors in Code Mirror, meaning it's not easy (or near impossible) for users to do.

CodeMirror.net has an addon listed, "mark-selection.js". Its demo shows normal change of text color when something is selected / highlighted. If codemirror had that ability, there'd be no need for the simple addon.

However, I didn't find details (anywhere) how or if addons could be installed when codemirror is embedded in an app like Fx. Discussions I found on using CM addons sounded like if using it as a stand alone editor.

FYI - everyone, codemirror.net has "themes" (CSS files) that change mostly syntax coloring (have previews). They would be editable. I think they'd have to replace the "default theme" in "codemirror.css," in omni.ja, then repack omni.ja.

Unless you wanted most of the default theme's colors changed, it'd be easier to copy the theme's code, then put it in the firefox profile folder: chrome_debugger-profile, in a userChrome.css file you create.

You can view codemirror.css contents by pasting: chrome://devtools/content/shared/sourceeditor/codemirror/lib/codemirror.css, in Firefox's URL bar. It controls colors in Style Editor in devtools.

There is a dark-theme.css file.

• https://dxr.mozilla.org/mozilla-release/source/devtools/client/themes/dark-theme.css

I see what you mean with the BG selection color.

These rules in codemirror.css and variables.css seem to apply.

• resource://devtools/client/themes/variables.css

.CodeMirror-line::selection, .CodeMirror-line > span::selection, .CodeMirror-line > span > span::selection {
    background: 
    #d7d4f0;
}
.CodeMirror-line::selection, .CodeMirror-line > span::selection, .CodeMirror-line > span > span::selection {
    background: #d7d4f0;
}
::selection {
    background-color: var(--theme-selection-background);
    color: var(--theme-selection-color);
}

Holy, Cannoli ! This has taken a long time. It's like that last bolt you have to remove on an engine. There's usually one that takes almost as much time as all the others, together. Some of the ways things work in Style Editor, or lack there of, look like things I might put together.

I finally found part of the problem - why search highlight colors (only in Style Editor) are so unruly.

The "search engine" in Style Editor apparently sucks (technical term). It doesn't have the capabilities of the other dev tools. Style Editor won't use a 2nd color for unfocused search matches (don't think). You also have to continually hit Ctrl+g to advance to next search hit instead of Enter or space bar.

It may have to do w/ Mozilla's tinkering, but using 2 .cm-searching background colors - one below the other, just uses the 2nd value for focused & unfocused matches.

And, Mozilla added a file, mozilla.css with code for codemirror searching. As you know, CSS code for Style Editor has ".cm-..." or, "CodeMirror-...." in the selectors. Plus the code from codemirror.css. Now we're trying to add more codemirror searching code to a userChrome.css file. Suffice to say, background colors I entered for search highlight were not what came out the other side.

Not sure if something for focused search hits would work, like .cm-searching .CodeMirror-focused .CodeMirror-selected { background-color: <focused color>,

I managed to make search matches visible - mostly by using a ti, uh, hot pink for text color & the border, under the highlighted background around search hit - color: #FF00ED !important;.

There's a very small amount of color or transparency difference in focused & unfocused search hits. Most wouldn't notice it.

I'm not sure if the code in mozilla.css can be overridden. I tried the usual tricks & didn't work. We could modify the codemirror.css & mozilla.css files in omni.ja, but the next Fx update would undo it.

See mozilla.css:

• resource:///chrome/devtools/content/shared/sourceeditor/codemirror/mozilla.css
• https://dxr.mozilla.org/mozilla-release/source/devtools/client/shared/sourceeditor/codemirror/mozilla.css

And after the update from Fx 73.0.1 to 74.0, all my customizations stopped working (in userChrome.css in the /chrome_debugger_profile/chrome/ folder.

It's too much work making it where it's usable (for me), to have it disappear. It's happened a lot in Fx, over the years. Oh well.

I've used some text editors for years, that most of the custom styling / preferences never just stop working after an upgrade. Not many would stand for that.

Note that /chrome_debugger_profile/chrome/userChrome.css is used by the Browser Toolbox and not by the regular Inspector.

• https://developer.mozilla.org/en-US/Tools/Browser_Toolbox

You may also have to add the pref to /chrome_debugger_profile/prefs.js to enable these CSS file just like required for chrome/userChrome.css in the main profile folder.

• toolkit.legacyUserProfileCustomizations.stylesheets = true

Thanks. "toolkit...stylesheets" pref was already in /chrome_debugger_profile/ prefs.js .

A couple of Fx upgrades ago, the customizations worked fine. After the update, something in userChrome.css caused black screens in Fx. Haven't done that yet, but will.

Last time, looked the userChrome over & compared it to a BU using a file comparison utility - no changes. I copied the full contents to a new userChrome file - instant fix.

Same thing happened yrs ago, using Stylish under Windows. Nothing had changed in the styles - nothing visible, anyway. Copied it all to a new styles.sqlite file - instant fix.

If it was a change in Fx, where some code no longer works, then copying it to a new userChrome file would do nothing. If the code was damaged, copying it to a new file would do nothing.

If copying content to a new file with the same or correct userChrome.css name worked then it is likely that there was a problem with the original file like the name (possibly hidden extra file extension: userChrome.css.css or userChrome.css.txt) or not a plain text file as the most common causes.

That's one theory I considered. But since I use a text editor & set the new file's type = CSS, it wouldn't change syntax coloring (like it did) if it thought it was another file type. The usual scenarios I've seen it (very few times) is right after a Fx update. Fx updates shouldn't mess with profiles, so I don't know.

Speaking of which, is there anything about changes / new code in latest stable Fx 74.0 - Linux, to cause formerly working CSS "theme" for syntax coloring devtools to stop working? Either in browser toolbox (Ctrl Shft Alt I) or web console (Ctrl Shft K)?

I had the code below in the ~/.mozilla/firefox/1mw6zdff.fx-72-mint-01-09-2020/chrome_debugger_profile/chrome/userChrome.css It worked - I believe in Style Editor & Debugger. I was just playing to see what worked for what tool. I got the code off a website. It worked until updating to Fx 74.

I tried several tweaks to make it work again - no success. The code (from userChrome.css) didn't show in the Inspector's rule pane as being overridden by something else. The code didn't change.

Even though the codemirror CSS lexer code I found isn't the same as code mirror syntax themes code, from https://codemirror.net/theme/, it worked for some tools in Fx 73.0.1.

root.theme-dark {

 --theme-selection-background: #078BE9 !important; /*brite blue; chg's selected BG in Inspector; duplicate of rule above*/
 --theme-selection-color: #D0D0D0 !important;
 --theme-selection-background-semitransparent: rgba(29, 79, 115, .5) !important;

 --theme-selection-focus-background: #3769FF !important;
 --theme-selection-focus-color: #FFFFFF !important;
 --theme-splitter-color: black !important;
 --theme-comment: #BFBFBF !important; /*gray*/

 --theme-body-color: #97C5FB !important;
 --theme-body-color-alt: #b6babf !important;
 --theme-content-color1: #a9bacb !important;
 --theme-content-color2: #8fa1b2 !important;
 --theme-content-color3: #5f7387 !important;

 --theme-highlight-green: #70bf53 !important;
 --theme-highlight-blue: #46afe3 !important;
 --theme-highlight-bluegrey: #5e88b0 !important;
 --theme-highlight-purple: #6b7abb !important;
 --theme-highlight-lightorange: #d99b28 !important;
 --theme-highlight-orange: #d96629 !important;
 --theme-highlight-red: #eb5368 !important;
 --theme-highlight-pink: #df80ff !important;

 /*** Colors used in Graphs, like performance tools. Mostly similar to some "highlight-*" colors. 

• • • /

 --theme-graphs-green: #70bf53 !important;
 --theme-graphs-blue: #46afe3 !important;
 --theme-graphs-bluegrey: #5e88b0 !important;
 --theme-graphs-purple: #df80ff !important;
 --theme-graphs-yellow: #d99b28 !important;
 --theme-graphs-orange: #d96629 !important;
 --theme-graphs-red: #eb5368 !important;
 --theme-graphs-grey: #757873 !important;
 --theme-graphs-full-red: #f00 !important;
 --theme-graphs-full-blue: #00f !important;

 --tab-line-selected-color: #ADF5FE !important; /*light cyan*/

}

 /* --theme-body-background: #14171a !important; /* chg'd Style Ed BG - all panes
 --theme-sidebar-background: #181d20 !important; /* chg'd style editor sidebar*/

/* --theme-contrast-background: #b28025 !important; commented on 2020-03-05; chk if prob. w/ mozilla.css :108 */

/* --theme-tab-toolbar-background: #252c33 !important; /*works style editor*/ /* --theme-toolbar-background: #343c45 !important;*/