Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Custom CSS may fail when Chrome's #enable-force-dark flag is enabled #111

Closed
Koolstr opened this issue Jan 28, 2020 · 14 comments
Closed

Custom CSS may fail when Chrome's #enable-force-dark flag is enabled #111

Koolstr opened this issue Jan 28, 2020 · 14 comments

Comments

@Koolstr
Copy link

Koolstr commented Jan 28, 2020

The Custom CSS field in vimium C's options does not apply any values when the Chrome flag of Force Dark Mode (#enable-force-dark) is set to Enabled. I've tested with it disabled, and the same kinds of CSS statements work in that case only. For example, .LH { color: green; } works only when the flag is disabled.

(As an aside, how can the background color of the Link Hints be changed? I can't get a CSS statement which seems to work at changing that. Vimium C really needs either clear documentation on how to use the Custom CSS field (it's not obvious nor natural) and/or a CSS selector reference sheet, or most ideally some designated fields for changing basic/common UI elements, such as Link Hint background and text colors.)

There is a real need for the CSS override to be working in this scenario, since the browser's forced dark mode also inverts the color of the text in the Link Hints. Thus, we end up with white text on yellow background, which is really hard to see, and without Custom CSS support, I can't add a workaround. I imagine you can fix this by including some check on the browser's flags to see if it is enabled, and if so, either prevent the color inversion, or invert it yourself so that it will get re-inverted back to the right color by Chrome.

Please make sure the Custom CSS works when dark mode is enabled, and ideally, if possible, add support for forced dark mode, so that Link Hints don't become inverted with the rest of the page, so that custom styling isn't necessary to begin with.

@gdh1995
Copy link
Owner

gdh1995 commented Jan 29, 2020

Forced Dark

As far as I've tested, CSS rules about colors will be modified forcibly by Chrome if it's in "Force Dark" mode, and all of color: #000, #111, #222 only cause white text color. So it seems that this incompatibility is hard to work around. Then you'll need to use some other colors to replace current "black" text color.

Why do you not use system dark mode? Vimium C has "Auto switch between light and dark mode", and it relies the media query (prefers-color-scheme: dark) to apply its dark styles when system is in dark mode. But in Force Dark mode, prefers-color-scheme reports light so no enough info can be used to tell it.

I need more time to test and investigate related detection methods. If you know how to tell this mode from normal light mode, please add it here.

Customize Vimium C UI

Most styles of Vimium C's UI are in https://github.com/gdh1995/vimium-c/blob/master/front/vimium-c.css , and rules in Custom CSS will override those in vimium-c.css, if only their selectors are in a same level (or higher, of course). You may use Chrome's Developer Tools to see UI elements of Vimium C. They are inside a shadow tree next to <body>:

image
When Vimium C has detected (system) dark mode, it will add a classname of D to its top-level UI elements.

Styles of Vomnibar are in https://github.com/gdh1995/vimium-c/blob/master/front/vomnibar.html.
And in Custom CSS, rules after /* #omni */ will be added to it.

@gdh1995
Copy link
Owner

gdh1995 commented Jan 29, 2020

Well, Chrome now supports a command-line argument of --force-dark-mode, and it can tell Vimium C prefers-color-scheme is dark. Please try it.

@Koolstr
Copy link
Author

Koolstr commented Feb 6, 2020

Thanks for the quick response.
My OS is already set to use the system's native dark theme, and I actually had that --force-dark-mode flag enabled already (I was using the feature before they even added it as an option in chrome://flags), so the latter is not the cause nor a means of prevention. I've tested with it removed, and the results are the same.

Thanks for pointing out the shadow div. It was useful for experimenting and for finding the right selectors. With this, I've manged to find a color combo which works for me and with the browser's color inversion, so thank you. The Custom CSS setting does seem to be working properly, given the circumstances.
It looks like there are a number of colors which avoid the color conversion to white or black, all of which are colors I had not tried to previously assign.

You can handle this bug however you like at this point. Feel free to close it, but I suggest keeping it open until you find and/or implement a workaround, or at the very least include this caveat in documentation (preferably in the much-needed documentation for Custom CSS, which you've already half-written up here).

@gdh1995
Copy link
Owner

gdh1995 commented Feb 7, 2020

On my Win10, --force-dark-mode and the runtime flag #enable-force-dark are not the same:

  • #enable-force-dark=Enabled means to force to use dark colors, but not tell Vimium C that it's in dark mode
    • some colors in CSS rules are always replaced
  • --force-dark-mode means to force all to be in dark mode, while a page can still use light color schemes.

Tested on Chrome 79 and 80.

@gdh1995
Copy link
Owner

gdh1995 commented Feb 7, 2020

BTW, could you provide those colors you found? Are they neither so dark nor so light, in order to avoid replacement?

@Koolstr
Copy link
Author

Koolstr commented Feb 7, 2020

They seem functionally identical, excluding the state which gets reported to your extension. Either way, I've been running both of those flags already (with the latter assigned via command line), I haven't been confusing one for the other. I do still believe that they fundamentally serve the same purpose though, so I feel like I should be removing the command line argument flag, since it shouldn't be needed anymore, now that it has a native flag option in Chrome.

I presume that is why the colors remained intact. These are the colors I'm using:

.D > .LH { background: green; }
.LH { border: 0.5px solid lightgreen; }

Text is still being forced to white, which looks fine with this color scheme.

@gdh1995
Copy link
Owner

gdh1995 commented Feb 8, 2020

As far as I've tested, they're not the same (below are my snapshots), so I think your #enable-force-dark=Enabled has overridden --force-dark-mode, and then made it have no effects.

  1. normal mode:
    1 normal

  2. the flag #enable-force-dark is "Enabled"
    2 flag-enable-force-dark

  3. --force-dark-mode in command line and turn off "Auto dark mode" on Vimium C
    3 argument-force-dark-mode

  4. --force-dark-mode in command line and turn on "Auto dark mode" on Vimium C
    4 argument-force-dark-mode-2

BTW, on Win 10, --force-dark-mode will also make the address bar of browser dark.

@Koolstr
Copy link
Author

Koolstr commented Feb 9, 2020

It's an interesting theory that one is overriding the other, but the behavior you've pointed out is not in line with what is being exhibited by me.
I've tried running with just the --force-dark-mode command line flag, and the browser is not activating any dark theme anymore. I wonder if the flag has been deprecated. Yet, the fact that it is working for you has me wondering if maybe there is something wrong with my instance of Chrome instead.
Also, the Settings page and the Vomnibar are both being appropriately dark themed under either flag.
I am now only running the #enable-force-dark flag, since the other seems to be unnecessary.

My concern is only with the Link Hints not getting a proper dark theme applied when the browser is dark. I'm hoping we can find a way to get it to work as expected.

@gdh1995 gdh1995 changed the title Custom CSS unsupported when Chrome's Force Dark Mode flag is enabled Custom CSS may fail when Chrome's #enable-force-dark flag is enabled Feb 9, 2020
@gdh1995
Copy link
Owner

gdh1995 commented Feb 9, 2020

Not activating any dark them

It's because the normal "dark theme" is just a suggestion, and websites can decide themselves whether to use dark versions of colors or not. For example, Vimium C will follow dark theme only if you has enabled "Auto switch between light and dark mode". While most websites haven't update their code to follow it.

@Koolstr
Copy link
Author

Koolstr commented Feb 20, 2020

Isn't that something the --force-dark-mode flag is meant to override? The websites should be dark theme whenever that is active. Or are you suggesting that this flag doesn't force websites into rendering under a dark theme, but rather forces sending them the status that the PC is set to a dark theme (regardless of the actual applied theme)?

@gdh1995
Copy link
Owner

gdh1995 commented Feb 20, 2020 via email

@Koolstr
Copy link
Author

Koolstr commented Feb 21, 2020

My browser behavior is in line with that. So then this CSS issue is exclusive to the use of the Chrome flag, not the command line argument. Wish they weren't so similarly named.

@gdh1995
Copy link
Owner

gdh1995 commented Feb 24, 2020

Closed, because:

  • this issue can be bypassed easily, by modifying "Custom CSS for Vimium C UI" and replacing some color values.
  • there seems no clue for JavaScript to detect such overwriting .

@alexbarry
Copy link

alexbarry commented Mar 6, 2022

I stumbled upon this post when searching for a solution for this myself (edit: in a different project). It appears that the Chrome team has recently published a way to detect this:

https://developer.chrome.com/blog/auto-dark-theme/#detecting-auto-dark-theme

Additionally, someone pointed out that they had enabled no experimental flags at all, and simply had the Android system "dark mode" preference enabled, and they encountered this issue with a project that I worked on. So it appears that it is no longer something that only affects experimental flag users.

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

3 participants