darkreader: [BUG] Domains and Subdomains Behave Differently on Site List
After further reading, this appears to be a bug, and not a Broken Website. I’ve updated the issue to reflect that.
Dark Reader Version: 4.9.16
Bug Description
- In the case of toggling Dark Reader on a subdomain, the entry into the list is specific, i.e., only effecting
docs.gitlab.com, and notgitlab.comor any other subdomains. - In the case of toggling Dark Reader on a domain, the entry into the list is generic, i.e., it effects
gitlab.com, as well asdocs.gitlab.comand any other subdomain.
This behavior is inconsistent and seems more like a bug.
Potential Bugfix: Even adding a future that would allow you to manually input //gitlab.com to limit it to the domain (i.e., excluding sub-domains) would be a great way to compromise on this bug! 😄
A broader discussion on this started in this comment below.
ORIGINAL POST
Website https://docs.gitlab.com/ee/ci/quick_start/
How to Reproduce Steps to reproduce the behavior: An example of this is
- Go to Gitlab Docs website
- Attempt to activate Dark Reader
Expected behavior Dark Reader activates and Dark Reader generates a dark theme
Actual behavior docs.gitlab.com remains disabled
Screenshots
System info:
- OS: All OS’s (screenshot is from Arch; tried on macOS and Windows as well)
- Browser: Attempted with both Chrome and Firefox
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 9
- Comments: 21 (8 by maintainers)
Should be fixed now.
So here’s a prominent example of where I found this bug/feature to be the most frustrating:
If for whatever reason you disable
stackexchange.com, then every one of the ~166 subdomains (e.g.english.stackexchange.com,math.stackexchange.com,unix.stackexchange.com) will also be disabled.But not only disabled, also impossible to enable again the intuitive way of clicking the button:
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:
Hi @HatScripts and @BoltonBailey!
I almost forget to make a comment on this issue, but after @HatScripts comment I was turned and made a change to the existing PR(#2517) which if everything goes as plan should replace the current matching logic. The change was purely targeted to fix the subdomain problem matching more info at https://github.com/darkreader/darkreader/issues/373#issuecomment-720103647 and https://github.com/darkreader/darkreader/pull/2517#issuecomment-720103367
Regards, Gusted
Well, we have all waited for #2517 to be merged 😄
I experience the same problem. If there is a website
domain.comthat hassubdomain.domain.com, thedomain.comsetting for page specific on/off, carries over to thesubdomain.domain.com.As such, there is no way to disable the DarkReader on
domain.combut enable it onsubdomain.domain.com.I am having the same problem as @HatScripts with
stackexchange.comsubdomains. I generally have dark reader on for stackexchange, but in some cases I want to use Option-Shift-A to toggle, but I can’t due to my being on a subdomain where the superdomain interferes. The ideal functionality for me would be for the toggle button to only toggle the current domain and not affect subdomains, so that each of the subdomains can be toggled individually.We have
^and$implemented in the current URL logic. As seen un this code https://github.com/darkreader/darkreader/blob/master/src/utils/url.ts#L51Well, it is. But check for #373 how it in the future will look like.
Add this into your sitelist
^gitlab.comIt’s a bug/feature? It depends how you see it. If you need every subdomain controlled it’s a feature. But a bug if you just need the main domain. I’m hoping my PR #2517 can be merged soon in order to get it more controllable and than make more logic to get it working for subdomains/domain not having conflicts.