Any news on getting this merged and released? I'm really looking forward to a fix to #660

This is a breaking change, changing a main component. A lot of system relies on this.
Also it's still unclear how this should work #373 give a good explanation. I've tried pushing this multiple times to get this merged. But their are more bug/features that is more wanted over this.

Do you think it would be possible to publish on Chrome Web Store a beta version of Dark Reader that would include this PR and maybe others ?

Do you think it would be possible to publish on Chrome Web Store a beta version of Dark Reader that would include this PR and maybe others ?

That will be a hell to manage.

Also seems like conflicts in this PR time to update.

Okay, well, I see this PR merged in my dreams. xD

I hope that dream can be fillfulled this month.
I've seen plans to get V5 by end of the month 👀 released.

What do the latest commits pending review do?
Doing it the way Bitwarden does would be too huge a change most likely (and maybe overkill).
Maybe just a "whitelist" that over-rides the current blacklist? That way, we could whitelist specific subdomains and regexes.

Maybe just a "whitelist" that over-rides the current blacklist? That way, we could whitelist specific subdomains and regexes.

That wouldn't address other issues like the need to exclude subdomains from a "higher-level" allowlist, unless they also implemented the inverse solution. Even then, I don't think that would be flexible enough to allow for custom configurations per subdomain, only inclusion or exclusion from higher-level rules, although it would depend on the implementation I guess. Plus, it might have a scaling problem, like not allowing for customization of sub-sub-domains. To be fair, that's getting pretty in the weeds.

Pinging @Gusted.

Here is a Pull Request from you that has been sitting open for approximately 2 3/4 years.

In the meantime, I created a Dark Reader dynamic blacklist userscript that, among other things, manages this use case, using the darkreader-lock meta tag.

For example, it will disable filtering on github.com, gist.github.com and docs.github.com, while keeping it enabled on education.github.com.

@KaKi87 If you don't mind me asking, is it supposed to work automatically or does it need any input? Because I've been trying with alternativeto.net, and it doesn't detect the available-but-not-default dark theme.

is it supposed to work automatically

Yes.

I've been trying with alternativeto.net, and it doesn't detect the available-but-not-default dark theme

Are you using Violentmonkey, like recommended on my userscript homepage ?
By the way, I think we should discuss this at my repository, or on the Discord community linked on that repository, or at Violentmonkey's, but not here.

EDIT regarding @Jackenmen's message below : the blacklist doesn't have to be empty, just not contain sites supported by the userscript.

It seems universal enough for anyone who saw Kaki's comment that I figured I may as well mention it here. In order for it to work, you need to set "Theme generation mode" to Dynamic as it's the only one that supports darkreader-lock meta tag:

Additionally, you may want to make sure that your site list is configured such that it can actually make pages dark. One such configuration is to set it to "Not invert listed" with an empty list:

This is to confirm this bug with Dark Reader V4.9.62. Using Firefox V102.7 or Ungoogle Chromium V109.0.

For users facing this challenge, I published this easy, quick, and temporary workaround.

For developers interested to contribute to resolving this bug, you might be interested in this:

• Steps to reproduce
• Pull request at Better URL Matching #2517

@Gusted Will the subdomains rule for the global dark list still be enforced once this PR is merged ?

is there an update on this?

Is there anything we can do to help this get merged ?

If this PR is problematic to merge and is expected to stay open for a long time, I'm going to try to upload a fork of Dark Reader to https://addons.mozilla.org based on this branch (Don't worry, I'll change the name). That way, users can still get around the issue

@iTrooz I'd appreciate a CRX build as well if you can. Thanks

Hi @iTrooz, there are now 2 approaches: without regular expressions (like www.google.*.*) and with regular expressions (like /www\.google\..*?\//). Please leave a comment if anything is not covered here #373

If google.* still matches maps.google.com then it's still a problem.

Try www.google.* or ^google.*

Hi @iTrooz, there are now 2 approaches: without regular expressions (like www.google..) and with regular expressions (like /www.google..*?//). Please leave a comment if anything is not covered here #373

Hey @alexanderby ! I'm sorry, but I don't think I understood your message. Could you reformulate please ?

This week a support for Regular Expressions was added. When a pattern starts with / and ends with / it means it is a RexExp. It would be nice to track feedback in a single place. This is a source issue #373

I'm sorry, but I'm not interested in testing that feature if it doesn't help this PR get merged. I am mainly interested in working on the code in this PR in order to it to get merged. My motivation for this is that I'd like to control subdomain dark themes independently from the main DarkReader UI (I'm affected by #1896 (comment) which brought me here)

So, is there any way in which I can currently help, to get this PR merged ? (Or maybe you would accept a smaller PR to specifically handle subdomains independently ? But I'm not sure why this would be better, since nobody complained that this PR doesn't work ?)

This PR can't be merged unfortunately, but some features can now be reimplemented in several smaller PRs. Particularly the root domain issue (e.g. GitHub.com and docs.github.com) can be fixed in 1 line and seems like a low risk change that can be done quickly.

The Site List separation into enabled/disabled has been done, and it is unclear if the negative patterns will be still necessary. Anyway it should be also in a separate PR.

I'm sorry that it takes so long, unfortunately my life situation didn't let me look into the problem 3 years ago.

This commit allows www as a subdomain, but not anything else. I know that domains with www and without are technically different, but this will allow us to easily handle site lists, fixes configs etc. @iTrooz Let me know if it solves your problem.

This works perfectly, thank you !
As a site note, you may want to make the www subdomain and the main domain equivalent. If I go to https://example.com, disable the dark theme, and go to www.example.com, the "toggle theme" button doesn't do anything. You may want to make it toggle the dark theme for the main domain

I'm sorry that it takes so long, unfortunately my life situation didn't let me look into the problem 3 years ago

Don't worry, it's perfectly okay ! You are doing this in your free time, and at no point did I want to imply that the work you are putting into this was bad. Thank you and the maintainers in general for making such a good extension, and devoting time for it. It's really useful for me on a daily basis, and I'm thankful for Dark Reader to exist

In which version is this/will this be published to the stores ?
Thanks

Thanks, I see this www toggling issue and will try to make a fix.

If no other issues are found, it can go live next week (hopefully Mozilla will review the previous release soon).

I'm attaching a build if you want to try:
darkreader-firefox-4.9.70.1.zip