Generic css for addon options

[stonecrusher]

In about:addons the options of certain extensions have black font-colour on grey background. Very poor contrast.

tl;dr

If the background is changed to dark, also change the font colour to light! Is that possible? I guess it's an iframe or specifity problem?

It's coming from the variable --in-content-page-background, which I redefined from the FF default in color_variables.css

Longread if not possible:

Now the approach to make a unique style for every addon out there is impossible to ever finish. Of course it makes sense for the most used addons. But sometimes I just want to test some unknown ones for some days or don't want to open an issue for every little extension I have.

There are three possibilities I came up with:

1. Don't touch the moz-extension options iframe at all (so it will be an ugly white block, but better than unusuable with dark background)
2. Make a generic style which will target all @-moz-document url-prefix("moz-extension://") { } and will be overwritten by the specific styles you made. This might also break certain options pages and needs the possibility to define exlusions, which is only possible by regex and overcomplicates it
3. Make a generic style which will target only UUIDs the user specified manually

So it could look something like this at the end:

@-moz-document url-prefix("moz-extension://extension1_UUID/"),
url-prefix("moz-extension://extension2_UUID/"),
url-prefix("moz-extension://extension3_UUID/"),
url-prefix("moz-extension://extension4_UUID/")  {
    body,
    body * {
        background-color: var(--dark-1) !important;
        color: var(--light-1) !important;
    }
    button, label, texarea, form, whateverspecialgenericelement {
      background-color: var(--light-2) !important;
      color: var(--dark-1) !important;
    }
}

p.s.: Extensions whose options open in their own tab are not affected by faulty dark background (and shouldn't be affected by the generic style).

Some screenshots:

[overdodactyl]

After doing a little testing, I think option 2 (generic styling) might be a really good way to go. The following code works for all but one extension I have that has options in the about:addons section:

@-moz-document regexp("^moz-extension.*(options)\.html$") {
  body * {
      color: var(--in-content-page-color) !important;
  }
  * {
    border-color: var(--in-content-box-border-color)!important;
    text-shadow: none!important
  }
  select,
  select * {
    color: black !important;
  }
  a {
    color: var(--in-content-link-color) !important;
  }
  h1 {
    color: var(--in-content-category-text-selected)!important
  }
  fieldset {
    border: 2px solid!important;
    border-color: var(--in-content-box-border-color)!important
  }
  textarea,
  input[type="input"],
  input[type="text"],
  input[type="number"],
  input[type="url"] {
    -moz-appearance: none!important;
    background: var(--in-content-box-background)!important;
    color: var(--in-content-page-color)!important;
    border: 1px solid!important;
    border-color: var(--in-content-box-border-color)!important;
    margin-left: 3px !important;
    padding-left: 3px !important;
  }
  textarea {
    padding: 5px 5px 5px 5px !important;
  }
  button,
  input[type="submit"] {
    -moz-appearance: none!important;
    background-image: none!important;
    background-color: var(--in-content-page-background)!important;
    color: var(--in-content-page-color)!important;
    border: 1px solid!important;
    border-color: var(--in-content-box-border-color)!important;
    border-radius: 3px!important
  }
  button:hover,
  input[type="submit"]:hover {
    background-color: var(--in-content-box-background-hover)!important
  }
}

Using this would also cut back a large amount of redundant code in the webextension-tweaks directory as well.

[stonecrusher]

Oh no, my last post is gone somehow.

The short version: I don't know how to inspect that options iframe. Just doesn't work here :-/ I downloaded and unpacked some extensions' .xpi to look at the code and came up with some changes that make it work for most of my extensions. Still not perfect, but conveniant on a wide scale.

If we investigate and develop it a bit further imho it's definitely worth merging into the project.

@-moz-document regexp("^moz-extension:\\/\\/.*(options|preferences|index|settings)\\.html$") {
  * {
    color: var(--in-content-page-color) !important;
    background-color: var(--in-content-page-background)!important;
    border-color: var(--in-content-box-border-color)!important;
    text-shadow: none!important
  }
  select,
  select * {
    color: black !important;
  }
  a {
    color: var(--in-content-link-color) !important;
  }
  h1, h2, h3, h4, h5, h6 {
    color: var(--in-content-category-text-selected)!important
  }
  fieldset {
    border: 2px solid!important;
    border-color: var(--in-content-box-border-color)!important
  }
  input  {
    background: var(--in-content-box-background)!important;
    color: var(--in-content-page-color)!important;
  }

  textarea,
  input[type="input"],
  input[type="text"],
  input[type="number"],
  input[type="url"]  {
    -moz-appearance: none!important;
    background: var(--in-content-box-background)!important;
    color: var(--in-content-page-color)!important;
    border: 1px solid!important;
    border-color: var(--in-content-box-border-color)!important;
    margin-left: 3px !important;
    padding-left: 3px !important;
  }
  textarea {
    padding: 5px 5px 5px 5px !important;
  }
  button,
  input[type="submit"] {
    -moz-appearance: none!important;
    background-image: none!important;
    background-color: var(--in-content-page-background)!important;
    color: var(--in-content-page-color)!important;
    border: 1px solid!important;
    border-color: var(--in-content-box-border-color)!important;
    border-radius: 3px!important
  }
  button:hover,
  input[type="submit"]:hover {
    background-color: var(--in-content-box-background-hover)!important
  }
}

[overdodactyl]

I don't know how to inspect that options iframe. Just doesn't work here :-/

Easiest way is to go to about:debugging#addons, and click "Debug" for whatever extension you want to inspect - this will bring up the Browser Toolbox. You can then choose what frame you want to inspect using the button in the top right (rectangle with two squares below):

This is also the easiest way I've found to inspect extension popups as well.

The biggest issue I'm seeing is that there's no standard when it comes to the name of html pages. Most seem to end in options.html for the settings in about:addons, but there are certainly others (namely those you pointed out - settings, index, preferences). Those later ones seem to be more frequently used for settings pages that are outside of about:addons, however. When that's the case, the generic styling can cause quite a few problems. Since there's no definitive standard (in some cases, options.html is also used for external settings pages), I'm wondering if it would be better to actually use the third option you suggested.

Doing so would still cut back on redundant code and it would make it easier for users to make quick fixes, but it would prevent the generic styling from creating even more problems.

Thoughts?

[stonecrusher]

Aah, good old debugging. I never think about it. Should have known. Works, thanks!

The biggest issue I'm seeing is that there's no standard when it comes to the name of html pages

Yes but I didn't see many more out there than the ones I listed. Do we even need to specify them?

used for settings pages that are outside of about:addons

Yeah but those should be styled too, no? Example addon with external page

So target everything but just not the popups because they are most likely to break? Are they really? Of course a complicated one like uBO will require special treatment.

Another possibility is to provide and activate generic styling (most comfortable - would be suggestion number 2) but also give examples for exclusions so that users can easily do that by themselves. In my experience RegEx knowledge is not very common among people who know CSS.

I vote for us doing more testing before going live and providing a regex like

/* Exclude extensions from being styled by adding their UUID in the given scheme */
@-moz-document regexp("moz-extension:\\/\\/(?!UUIDexmpl-1111-1111-1234-012345678910|UUIDexmpl-2222-2222-1234-012345678910|UUIDexmpl-3333-3333-1234-012345678910)\\/.*")

[overdodactyl]

Yes but I didn't see many more out there than the ones I listed. Do we even need to specify them?

I think we do. Painting with too broad of a stroke is only going to cause a lot more problems I think. If we just start with moz-extension, then everything will be styled - about:addons, popups, settings pages, etc. I currently don't have the time or help to make sure every extension is properly styled. Using things like:

* {
    color: var(--in-content-page-color) !important;
    background-color: var(--in-content-page-background)!important;
    border-color: var(--in-content-box-border-color)!important;
    text-shadow: none!important
  }

is going to break a lot of extensions. Generally speaking, I think it's best for people to opt-in to having webextensions (settings pages and popups) styled rather than having to opt out. If people download ShadowFox and see several extensions are broken, I think their first reaction will be to uninstall it, not find out how to create exceptions.

Yeah but those should be styled too, no?

Ideally, yes. But again it's a matter of me not being able to maintain styling for a large number of extensions. Keeping up with just the ones I personally use is already a decent amount of work.

So target everything but just not the popups because they are most likely to break? Are they really?

Both popups and external settings pages are much more likely to break with generic styling (simply because they have more involved with them than a little text and entry boxes).

I vote for us doing more testing before going live

Definitely agree there :)

[stonecrusher]

Painting with too broad of a stroke is only going to cause a lot more problems I think.

In general, yes. Although I thought all those things should be styled. So let's make it specific. Edit: See next post - generic works well.

If people download ShadowFox and see several extensions are broken

Unfortunately that's the case at the moment and was the reason why I opened this issue. Just making the background dark doesn't work. Either don't touch moz-extension urls at all by default or make a general style and try to target as many extensions (options pages) as possible. Just overriding everything works pretty well here.

I think their first reaction will be to uninstall it, not find out how to create exceptions.

Which speaks for solution number three: Opt-in for a generic style and the already existing specific ones.

I'm here to test and do my best with CSS. Currently I have 20 extensions active but will make another profile containing the most popular ones. With the current setup of the generic style it is definitely an improvement for me. Even if there are still some things which don't look very well, at least I can read everything and use it.

Don't know if I have time tonight, but I can start a list of extensions and compare if their options pages work well.

[stonecrusher]

So I did a lot of testing and came up with following questions: You can't distinguish between internal and external (opened in new tab) options? Without using the specific style for e.g. Smart HTTPS, why does it have a dark background colour?

I got pretty awesome results with this generic.css. Plus all the stuff is dark compared to the default setup.

The list contains the 25 most installed addons plus some of my own plus the ones you already had special styles for. Of course I couldn't deeply test so many in that time, just looked if everything is readable.

p.s.: Maybe you could help with a selector to change the top text of a dropdown? That's still a flaw, black on grey.

[overdodactyl]

Wow, thank you for all this work! Sorry I didn't have time to look at it yet, but I'm about to dive into a bit more.

You can't distinguish between internal and external (opened in new tab) options?

I don't believe so, no. The only thing I was seeing was that most addons that had preferences in about:addons utilized options.html, but that wasn't always the case.

Without using the specific style for e.g. Smart HTTPS, why does it have a dark background colour?

It's coming from the variable --in-content-page-background, which I redefined from the FF default in color_variables.css

Maybe you could help with a selector to change the top text of a dropdown?

Could you possible upload a screenshot or direct me to where I could see that problem?

[stonecrusher]

Sorry I didn't have time to look at it yet, but I'm about to dive into a bit more.

Don't worry, take your time. I'm happy you like my suggestions.

You can't distinguish between internal and external (opened in new tab) options?

I don't believe so, no. The only thing I was seeing was that most addons that had preferences in about:addons utilized options.html, but that wasn't always the case.

Yeah that's what I feared. Distiguishing just by url is proven to not work, they are arbitrary. Like Adblock Plus has an external options.html without being in any subfolder. But it's not so important as we however now try to darken everything.

Without using the specific style for e.g. Smart HTTPS, why does it have a dark background colour?

It's coming from the variable --in-content-page-background, which I redefined from the FF default in color_variables.css

So that's the culprit for extensions options to be unreadable in default SF settings. If geneneric.css won't be activated by default, we should find a workaround to keep the white background in extensions.

Could you possible upload a screenshot or direct me to where I could see that problem?

Using generic.css with SF default settings, open the options for Google Translator Extension. The dropdown for language setting is unreadable. You can see a screenshot of that in my results sheet. Same for Video Blocker

[overdodactyl]

Do you use mac, linux, or windows?

[stonecrusher]

Windows 8.1 Windows 7 in VM Linux MINT in VM I usually test with 8.1 because it's most similar to Windows 10 which is the most used OS

[overdodactyl]

So it hasn't been implemented in the Windows updater script yet (I don't have Windows, so I haven't been able to do it myself), but the mac and linux ones have a new-ish feature that can automatically find and insert the UUID's of extensions.

This could be a helpful way to "force" fixes onto webextensions that have problems. Just something to consider in the mix of what to do with the generic styling.

The following makes the background white for webextensions prefs in about:addons:

#addon-options {
    background-color: white !important;
}

[stonecrusher]

Trying to fix the colour of option elements I came across some firefox bugs:

• If you don't use -moz-appearance: none you can't change the background color in every situation
• If you use -moz-appearance: none it works but the dropdown arrow will vanish

It's not the nicest solution, but I'd better keep the dropdown arrow and set the font colour to a grey which is readable with dark and light background to treat the cases where it doesn't work.

I'm trying to find a workaround using own CSS-created arrows via ::after pseudo-element.

/edit https://fabriceleven.com/design/clever-way-to-change-the-drop-down-selector-arrow-icon/ should work

[overdodactyl]

Thanks for the bugzilla links! I had been trying to mess around with those as well and was running into the same problem.

I had been playing with using an .svg drop down icon to replicate a somewhat similar look, but I haven't been able to find anything I'm super happy with. On top of that, it's kind of a hacky approach and I'm not convinced it would work well in all cases and on all OS's.

::after might not be a bad idea, I was applying them as a background image on the right most side.

[overdodactyl]

@stonecrusher, I'm thinking of going with option 3...would you be good with that? I would add some "generic placeholders" after putting in the spots for all the one's we've verified it works for. It would look something like this then:

@-moz-document url-prefix("moz-extension://1_Click_YouTube_Video_Downloader_UUID/html/options.html"),
               url-prefix("moz-extension://AutoCopy_UUID/options.html"), 
               url-prefix("moz-extension://Custom_Titlebar_Text_UUID"), 
               url-prefix("moz-extension://Octopatcher_UUID"),
               ...
               ...
               url-prefix("moz-extension://generic_styling_1_UUID"),
               url-prefix("moz-extension://generic_styling_2_UUID"),
               url-prefix("moz-extension://generic_styling_3_UUID")
               ... 
{

[overdodactyl]

I've got a new branch going for testing:

https://github.com/overdodactyl/ShadowFox/tree/generic_styling

The generic styling css can be found here:

https://github.com/overdodactyl/ShadowFox/blob/generic_styling/css/userContent-files/webextension-tweaks/generic_style.css

[overdodactyl]

Any thoughts regarding the current approach @stonecrusher?

[stonecrusher]

Sorry, didn't have time to think about it and test it yet. Maybe tonight. Weather is awesome here in Europe

[overdodactyl]

Enjoy the weather - no rush at all :)

[stonecrusher]

So, I was messing around a bit with the new code. Good idea putting in sections for popups and codemirror!

At the moment I have the problem that it is unusuable for me without automatic updater for all those addons with a UUID for each. I'll see if I can make it work. The thing is, in my working profile I have many other customizations and therefore do updates manually anyway because I don't trust installers that might overwrite my userChrome.css. Even if it backs it up I have to look and merge... I usually keep customizations completely separate in subfolders, only having single import lines in my userContent.css.

/edit webextension_mappings.txt looks good, but no UUIDs are ported to generic_styling.css

1_click_youtube_video_downloader|YoutubeDownloader@PeterOlayev.com
autocopy|autocopy@mozilla.org
back_to_close_we|back2close@bomjacob.github.io
brief|brief@mozdev.org
containers_on_the_go|{7e56c1ad-71c3-47fe-bdba-372c7770e0cb}
css_exfil_protection|{7fc8ef53-24ec-4205-87a4-1e745953bb0d}
cookie_autodelete|CookieAutoDelete@kennydo.com
custom_titlebar_text|{b5a43a70-4092-4899-9c44-63799150b35e}
dark_mode|{174b2d58-b983-4501-ab4b-07e71203cb43}
decentraleyes|jid1-BoFifL9Vbdl2zQ@jetpack
display_anchors|display-anchors@robwu.nl
enhancer_for_youtube_UUID|enhancerforyoutube@maximerf.addons.mozilla.org
flash_and_video_download_UUID|{bee6eb20-01e0-ebd1-da83-080329fb9a3a}
google_translator_for_firefox|translator@zoli.bod
greasemonkey|{e4a8a97b-f2ed-450b-b12d-ee082ba24781}
https_everywhere|https-everywhere@eff.org
mind_the_time|jid0-HYNmqxA9zQGfJADREri4n2AHKSI@jetpack
multi_account_containers|@testpilot-containers
multiple_tab_handler|multipletab@piro.sakura.ne.jp
neat_url|neaturl@hugsmile.eu
new_tab_from_location_bar|newtabfromlocationbar@piro.sakura.ne.jp
noscript|{73a6fe31-595d-460b-a920-fcc0f8843232}
octopatcher|octopatcher_wowmotty@gmail.com
open_in_new_tab|{6f5f4891-9637-41f9-9ee5-3a0ac02cf254}
rename_tab_title|renametabtitle@mozilla.org
request_control|{1b1e6108-2d88-4f0f-a338-01f9dbcccd6f}
skip_redirect|skipredirect@sblask
smart_https|{b3e677f4-1150-4387-8629-da738260a48e}
smart_referer|smart-referer@meh.paranoid.pk
tab_auto_close|mobislan@users.noreply.github.com
tab_suspender|{e225ac78-5e83-484b-a16b-b6ed0924212f}
text_link|{54BB9F3F-07E5-486c-9B39-C7398B99391C}
tree_style_tab|treestyletab@piro.sakura.ne.jp
tridactyl|tridactyl.vim@cmcaine.co.uk
ublock_origin|uBlock0@raymondhill.net
ubo_scope|uBO-Scope@raymondhill.net
umatrix|uMatrix@raymondhill.net
vim_vixen|vim-vixen@i-beam.org
violentmonkey|{aecec67f-0d10-4fa7-b7c7-609a2db280cf}

However, to be really generic I still prefer using something like @-moz-document regexp("^moz-extension:\\/\\/.*\\.x?html?$") as it works better than the previous default (more darkstyle, less breaking) and then adding known defective addons via UUID. Generic will cover almost all, which is impossible to do manually. I can't really see the advantage in listing all the addons there. Conceptually in this case I prefer blacklist whereas you prefer whitelist, right? But in fear of what?

Your plan is that you add extensions which you tested and know to work with generic styling and the user has to add the ones you didn't list (but doesn't know if you didn't list them because they don't work or because you don't know about them)? And the next update the users @moz-rules will be overwritten?

It's a bit... I don't know. Maybe I didn't get the concept or should it just be an internal restructuring to have less files? Couldn't make it work so far without manually looking for UUIDs and putting them in the right place. I need to have a look into updater issues with windows 8.1 (hopefully) this evening (used the .vbs script).

[opes]

This would be an awesome addition if possible. Have there been any updates on this? Or any assistance required in getting things solidified so a solution can be built out?

[stonecrusher]

@opes Actually it already is integrated. You need to add the UUIDs of your extensions to the generic_style.css.

Or you can try my "true generic" solution which saves you the time for searching and adding the UUIDs and gives you darkstyle everywhere but also has the risk for making something unreadable.

[opes]

Thanks @stonecrusher. I tried adding your CSS to both userChrome then userContent, but the options pages for the addons (that open within about:addons, not in a new tab) still had the black text on the dark background. Is there something I'm missing?

[stonecrusher]

still have the black text on the dark background

Then it's not working. Did you save the file & restart FF? The right place for the code is the userContent.css.

Imho it's better to create a new file custom_generic_darkstyle.css next to your userContent.css and add @import url("./custom_generic_darkstyle.css") at the very top of userContent.css. There still may be some addons which don't work properly. If you name one, I can try it and tell you if it works here.

[opes]

What I had done was place your CSS in ShadowFox_customization/userContent_customization.css, then ran the auto-updater script, which I verified that it resulted in your CSS being appended to userContent.css. The changes were saved and Firefox was restarted between each attempt.

After undoing the above, I then created the separate custom_generic_darkstyle.css and imported it as you recommended, but still to no effect. I will try a fresh install next to see if that works.

These were the two addons I tested against: Context Plus Quick Commands (Disclaimer: I am a contributor to both of these addons)

[stonecrusher]

That's what they look like for me: I think it just depends on what you use - import version of SF or the provided userContent.css Depending on your constellation the changes may be overwritten by following rules further down in the code.

[opes]

Okay, glad to know it's not specific to those addons. I'll keep investigating to see what's going on on my end. Thanks for looking into it!

Edit: @stonecrusher I found the issue. My chrome directory was symlinked to a folder I synced in Dropbox so I could share my customizations across my various devices automatically. This had been working fine, up until now. I'm assuming there's something going on with how Firefox loads userContent.css when it's located in a symlinked folder (or perhaps something related to how symlinks are recognized when in Dropbox). I copied the exact same code I was using above, but directly into a new, non-symlink chrome folder, and now it's working. All this means (for me) is that instead of running the auto-updater on one device and having the changes sync across all of them, I'll just have to run the updater on each device separately. Thanks again for your help!

[overdodactyl]

Thanks for giving this issue a "bump" @opes, and my apologies @stonecrusher for not having much action with it lately.

I will get those two addons added to the built in list.

---

Conceptually in this case I prefer blacklist whereas you prefer whitelist, right? But in fear of what?

My biggest concern with changing to a blacklist approach is that it can make entire addons nonfunctional/hideous. The general styling works really for preferences in about:addons and really simple popups, but not much beyond that. With the current approach, the worst that happens is settings are difficult to see. Obviously not optimal, but not a deal breaker for most people I imagine.

I think there's more potential to lose users due to the first problem than the later.

Ideally, users will report when an extension has a compatibility issue and it can be addressed from there.

[stonecrusher]

My biggest concern with changing to a blacklist approach is that it can make entire addons nonfunctional/hideous

I don't know, do you have examples?

the worst that happens is settings are difficult to see

It's the same for the generic one. But less often. I mean the generic one isn't fully developed yet, it's my draft, so rates can improve. Btw I consider black on darkgrey as nonfunctional and a showstopper for users. At least I can't read it if my screen brightness is below 50%.

The two extensions mentioned by opes are a good example. ContextPlus works with true generic, but not with default SF. QuickCommands doesn't work with both style types as of the black-on-grey-problem for default SF and the "special" preview box for true generic.

[overdodactyl]

I don't know, do you have examples?

It's going to be an issue with nearly any addon that has any sort of complexity beyond basic titles, check boxes, entry boxes etc. If an addon relies on something like button color or background color for it's state of activity, or text color, it will be lost. I disabled my other styling, and enabled just your "true generic" style:

uMatrix - unusable:

uBO - can't tell if it's active or inactive:

Violent Monkey - lose text editor colors and background states for active/inactive:

Multi-account containers - lose most of the styling:

Cookie AutoDelete - lose functionality:

These are just a few of the issues, there's some present with nearly every addon I have. For addons that have a native dark theme available, it will be overridden by this as well.

Obviously I have styles for these since I use them, but it's still representative of the overarching issue.

so rates can improve

It could improve, but since there's no definite standards for css selectors, colors, etc., it's going to be impossible to make it work for everything (or even most).

Btw I consider black on darkgrey as nonfunctional and a showstopper for users.

Settings aren't something that are accessed that frequently. I 100% understand it's not optimal, but having to brighten up your screen to adjust them isn't nearly as bad as having ugly or non-functional addons.

The two extensions mentioned by opes are a good example

For addons that have a compatibility issue, I don't think it's too much to ask of users to notify me. It's a matter of adding a few lines of code for a generic fix.

[stonecrusher]

uBO, uMatrix, Violentmonkey and CodeMirror already have specialized styles to fix that as you already mentioned. Other examples would have been more convincing :-/

active / inactive stuff is not adressed yet, is on todo-list.

I don't use Cookie AutoDelete. In what way does it lose functionality? Sure, the popup is not the prettiest anymore but it's dark and to me it looks like it works.

Most addons are rather simple and problems occur in the heavily styled ones. This is mostly popups, so we could exclude popups by default. Many addons don't even have a popup.

For addons that have a native dark theme available, it will be overridden by this as well.

There are almost none with dark theme (that I know of) and they can be easily excluded from the generic style. Actually there is not really a problem in overwriting a darkstyle with another darkstyle besides one of them might be considered less beautiful

issues, there's some present with nearly every addon I have

Unfortunately I cannot confirm that for my ~25 active extensions and cannot confirm that for the top 30 addons

it's going to be impossible to make it work for everything

Oh, it already is impossible. That was clear from the beginning. But I disagree and say it's possible for most.

Settings aren't something that are accessed that frequently.

With that argument this whole thread is redundant :-)

I 100% understand it's not optimal, but having to brighten up your screen to adjust them isn't nearly as bad as having ugly or non-functional addons.

Brightening up works for me (don't know about other people) and only at nighttime. Ugly is better than unreadable. Non-functional forces to make an exclusion. That's not as often the case than having to add every extension manually, especially every time you install a new one.

For addons that have a compatibility issue, I don't think it's too much to ask of users to notify me. It's a matter of adding a few lines of code for a generic fix.

Exactly the same goes for the true generic style.

If an addon relies on something like button color or background color

... it has a badly designed UI or is so complex that there has to be a specified style for it anyway

Oh and please don't read my answers in a bad mood, I am almost always friendly and out of experience afraid some people read some saltiness between the lines that was never meant to be there. Just trying to argument and dissect the problems to find the best overall solution at the end :-)

[opes]

What if the auto-updater script had a section in the UI where users could select from their currently installed extensions which ones to apply the generic style to? It could list just the extensions that don't have preexisting styles created for them. There could be a check/uncheck all option or a "use globally generic style for extensions without predefined rulesets" and a fair warning about the concerns regarding breaking extension functionality?

I know this could be a more involved undertaking, but it seems like it would address both of your concerns. Since it's already looking at the user's extensions to generate the internal UUIDs data, maybe that could be leveraged pre-install to populate the list?

[stonecrusher]

My current version of generic_addons.css

• Excludes popups
• Excludes certain addons you can define
• Recreates dropdown arrow, therefore dropdowns are dark now, too
• Doesn't target URLs ending with parameters, which will disable it for e.g. Tampermonkey editor
• Still will make stuff unfunctional which rely on color. E.g. kills CodeMirror syntax highlighting in Violentmonkey (so Violentmonkey should manually be excluded or targeted separately by violentmonkey.css). But most cases are solved by not targeting popups.
• Not for automatic updating. It's the advanced solution for people who know about the consequences.

Made good experience with it so far.

Click to expand code

``` /* Excluded extensions (you have to change the IDs according to your needs): - screenshots db82fa4f-cf33-45d6-bc24-e0621969fde6 - Stylus 9088eb03-b954-4556-a0f4-fabfa4336ef9 - uBlockOrigin dbc31577-a804-4d64-978e-8260ba7cbb22 */ @-moz-document regexp("^moz-extension:\\/\\/(?!db82fa4f-cf33-45d6-bc24-e0621969fde6|9088eb03-b954-4556-a0f4-fabfa4336ef9|dbc31577-a804-4d64-978e-8260ba7cbb22)[a-f0-9-]{36}\\/(?!(.*popup|.*monkey-menu)).*\\.x?html?$") { html, body { color: var(--in-content-page-color) !important; background: var(--in-content-page-background) !important; } body *:not(select):not(input):not(textarea):not(.green):not(.red):not(.blue):not(.active), article , aside { color: var(--in-content-page-color) !important; background-color: var(--in-content-page-background) !important; border-color: var(--in-content-box-border-color) !important; text-shadow: none !important; } input, textarea, select, code, .checkbox { background-image: none !important; } select { padding-right: 18px !important; color: var(--in-content-page-color) !important; background: var(--grey-60) !important; -moz-appearance: none !important; /* remove default arrow */ /* add custom arrow */ background-image: url(data:image/svg+xml;utf8,%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20width%3D%2248%22%20height%3D%2248%22%20viewBox%3D%220%200%2048%2048%22%3E%3Cpath%20d%3D%22M14%2020l10%2010%2010-10z%22%20fill%3D%22%23ccc%22%2F%3E%3Cpath%20d%3D%22M0%200h48v48h-48z%22%20fill%3D%22none%22%2F%3E%3C%2Fsvg%3E) !important; background-position: center right !important; background-repeat: no-repeat !important; background-size: contain !important; } a { color: var(--in-content-link-color) !important; } h1, h2, h3, h4, h5, h6 { color: var(--in-content-category-text-selected) !important; } fieldset { border: 2px solid !important; border-color: var(--in-content-box-border-color) !important; } input { background: var(--in-content-box-background) !important; color: var(--in-content-page-color) !important; } textarea, input[type="input"], input[type="text"], input[type="number"], input[type="url"] { -moz-appearance: none !important; background-color: var(--grey-60) !important; color: var(--in-content-page-color) !important; border: 1px solid !important; border-color: var(--in-content-box-border-color) !important; margin-left: 3px !important; padding-left: 3px !important; } textarea { padding: 5px 5px 5px 5px !important; } button, input[type="submit"] { -moz-appearance: none !important; background-image: none !important; background-color: var(--in-content-page-background) !important; color: var(--in-content-page-color) !important; border: 1px solid !important; border-color: var(--in-content-box-border-color) !important; border-radius: 3px !important; } button:hover, input[type="submit"]:hover { background-color: var(--in-content-box-background-hover) !important; } } ```

[overdodactyl]

Thanks @stonecrusher! I'll give this version some testing and get back :)

Again, my apologies with the (really) delayed responses. Maybe a combination of what you have here and @opes's suggestion with adding a few options in the updater would be the best approach to take.

[seascape]

Is this generic add-on .css implemented when the installer is used (and everything is concatenated into a few files -- I'm guessing not?) Is this generic theming still working the kinks out?

[stonecrusher]

Is this generic add-on .css implemented when the installer is used (and everything is concatenated into a few files -- I'm guessing not?)

No. This is what you currently get.

Is this generic theming still working the kinks out?

Well... It depends on the addons you have installed. I've tested mine and a few common ones and made good experience so far. You can give it a try by adding that custom generic style on top, so you don't have problems with the autoupdater. Do you know how to do that?