[BUG] [Stack Three Columns] Background is white whenusing a dark theme in Firefox + GM

[PurpleMagick]

Which userscript
Stack Three Columns

Describe the bug
When using Greasemonkey and the dark theme for Stack Overflow, the three column edit view that opens has a white background which makes many elements hard to read.

To Reproduce
Steps to reproduce the behaviour:

1. Change the Stack Overflow theme to Dark direct link.
2. On the URL https://stackoverflow.com/q/11227809/.
3. Click on on the edit link on any post, for example the question.
4. The background of the three panels is white instead of dark like the rest of the site.

Screenshot

Expected behavior
The three column layout to be dark. Preferably recognising the theme used the site.

Environment (please complete the following information):

• OS: Windows 10
• Browser: Firefox
• Browser Version: 77
• Userscript Manager: Greasemonkey

Additional context

The issue is somehow connected with how Greasemonkey handles the script. Most likely something to do with the isolation it applies. The issue doesn't show up in Tampermonkey (tested in ChromeVersion 75) nor in Violentmonkey (tested in Firefox 77).

The script is using background-color: var(--white); here . This matches the declaration the following rule from primary.css:

body {
 min-height:100%;
 display:flex;
 flex-direction:column;
 background-color:var(--white);
 /* truncated the rest for brevity */
}

Where the the --white is defined in stacks.css:

body.theme-dark {
 --white:#2d2d2d;
 --black:#fff;
 /* truncated the rest for brevity */
}

So, the --white should work and it does in other userscript managers, however GM has a different handling of styles from the userscript with regards to styles on the main site.

I don't know if there is an easy fix for this. My current workaround is to just use Violentmonkey for this script

[CertainPerformance]

Greasemonkey 4 has many issues, one of them being a sandbox that's hard to work with, especially when one needs to access the actual properties on the native page's window. The best solution that I recommend is what you've already doing, which is to use a better userscript manager. (Tampermonkey works as well - it is available for Firefox)

I just installed GM 4 in an environment just like yours to check things out, but couldn't reproduce the problem because the first time $ is referenced, the script silently stops executing (see the Greasemonkey issue linked above). I tried some things but don't see a way around that other than by injecting the script manually like below. If you've modified the script and it runs fine (except for the CSS), I'm curious, what have you changed?

I don't particularly want to officially support GM 4, but in this case, if you want to use it, it looks like you can inject a script tag into the page containing the userscript's code and it'll work properly. That is, replace:

// ==UserScript==
// ...metadata block...
// ==/UserScript==

/******/ (function(modules) { // webpackBootstrap
         // ... the entire userscript code ...
/******/ });

with

// ==UserScript==
// ...metadata block...
// ==/UserScript==

const userscriptSourceCode = () => {  ////// <--- add this

/******/ (function(modules) { // webpackBootstrap
         // ... the entire userscript code ...
/******/ });

};  ////// <--- add this, and add the below line
document.body.appendChild(document.createElement('script')).textContent = '(' + userscriptSourceCode.toString() + ')();';

[PurpleMagick]

I don't particularly want to officially support GM 4,

That's alright. I am OK with using another script manager. The main reason I used GM is because I had it installed since ages ago. But I do see that it is overly restrictive nowadays. I am fine with moving over to Violentmonkey. Not a fan of Tampermonkey since it went close sourced.

I am happy for the issue to be closed with the workaround for using a different userscript manager and the code change above.