Dark UI · uBlockOrigin/uBlock-issues · Discussion #1963 (original) (raw)

Finally the dark UI is here but in the logger, all is still horrible.
Tested on Windows 7 at moment.

You must be logged in to vote

may I request some changes?

Just to be clear, in the main commit for dark mode, I pointed out that I don't expect it to be complete everywhere, there is a lot of corners in uBO, and that I will fix as per feedback -- this is what we are doing here. So if you see a bad color choice, it's not because I thought this was a good idea, it's just something which I overlooked -- there were a huge amount of CSS-related changes and at some point I had to commit what I had without waiting to have 100% coverage by trying to find everything on my own.

View full answer

all is still horrible.

Elaborate on what is "horrible".

You must be logged in to vote

0 replies

horrible

How is this constructive? To be constructive you need to be very specific about what needs to be fixed, otherwise we have no idea what you think requires fixing, and no action taken as a result.

You must be logged in to vote

0 replies

Sorry guys you are right.

This screenshot is taken from Firefox 97 final and UBO 1.40.9b11 on Windows 7.

You must be logged in to vote

4 replies

I can reproduce the "Click to preview" issue, I will fix this.

I cannot reproduce the illegible line in the logger, mine is light text on dark background. Maybe you have remnant of customizations for uBO's CSS, you should remove all these to be sure they are not interfering with uBO's official support of dark theme.

Web Workers are always shadowed, perhaps shadows won't work with dark theme.

Any link which I can simply navigate to so that I get webworker entries?

Navigate to https://github.com/ with logger open and Dark theme enabled
Put 0,1 in the filter widget to filter web-worker entries.

Blinking white background when dark theme is active.

gif

Details

uBlock Origin: 1.40.9rc0 Chromium: 98 filterset (summary): network: 96192 cosmetic: 62224 scriptlet: 18070 html: 0 listset (total-discarded, last updated): default: user-filters: 0-0, never RUS-0: 41141-9, 7m easylist: 62829-20, 7m easyprivacy: 26696-113, 7m plowe-0: 3677-822, 7m ublock-abuse: 77-1, 7m ublock-badware: 3831-72, 7m ublock-filters: 30183-181, 7m ublock-privacy: 194-2, 7m ublock-unbreak: 1699-39, 7m urlhaus-1: 7611-0, 7m filterset (user): [empty] modifiedUserSettings: [none] modifiedHiddenSettings: [none] supportStats: allReadyAfter: 359 ms (selfie) maxAssetCacheWait: 229 ms popupPanel: blocked: 1 blockedDetails: github.com: 1

You must be logged in to vote

1 reply

@happysurf provide an exact URL which I can use to reproduce exactly what you get in your logger.

Ok I forced an update of one of uBO's list, and tabless network requests shows up fine in dark mode, i.e. light text on dark background, so I can't still reproduce that illegible line in your screenshot.

You must be logged in to vote

0 replies

Since we're talking about the logger's dark UI, may I request some changes?

mediumblue color for CNAME Screenshot

mediumblue is rather hard to read on a dark background. Especially when looking from a distance, suffering from eye-strain or generally for people with slightly worse vision.
blue is only slightly better - I'm proposing changing it to something like deepskyblue or cyan, if we need to stay with blue variants.

Changing the color to one of these lighter hues will also kinda fix the issue with shadowed web workers as mentioned in @happysurf 's comment and @uBlock-user 's reply.

Screenshot for comparison

Remaining elements with white backgrounds Screenshots

I know these fields don't have to be darker, considering their size, but some lightgrey would be better, IMO. (Also for their Dashboard counterparts - filter/search fields + dropdown fields)

Could we get these fixed, please?

You must be logged in to vote

6 replies

CNAME is #93a6ff in popup.

CNAME is #93a6ff in popup.

Yeah, I guess using #93a6ff/var(--popup-cell-cname-ink) will also work.
Point is, something lighter.

Cname in logger is just something I overlooked, I didn't choose this specifically, the proper one is the one already defined for the popup panel, so I will change this.

For the form widget, I prefer to let the browser or OS deal with these, I would expect it would do so when dark mode is set browser- or system-wide.

I have both system-wide and browse-wide dark modes and the dropdown entries remain dark, it's just the initial fields that show up white in uBO.

On my side I have these fields in a light color, including the drop down -- uBO does not change the background color on these, I decided to refrain from doing so a long time ago because of bad side effect in the appearance of built-in widgets. The filter expression overlay is a custom div though, so it will be affected by default background color.

You must be logged in to vote

1 reply

These dark CNAME lines are from closed tabs. Open github.blog -> close the tab.

You must be logged in to vote

0 replies

may I request some changes?

You must be logged in to vote

2 replies

All form widgets in all uBO panes are white on dark themes or when set to auto(browser theme set to dark.).

As said, I won't touch form widgets, this is opening a can of worms -- the appearance of these is controlled by the browser. If you expect them to be modified by dark theme in the browser, you will have to open an issue about this with the browser devs.

There's an issue with the selection color in CodeMirror (does picker use CodeMirror too?) if the window becomes inactive. E.g. when snapping two windows to screen edges to test filters on two different browser profiles.

You must be logged in to vote

5 replies

I'm going to have to research to find out if it's possible.

Slight correction. The color change also happens in the same browser window when shifting focus to another item (e.g. clicking outside the textarea in "My Filters" or when trying to drag the Picker box whilst its contents are selected).

Thanks. I'll try it out when the next rc goes live.

Dark theme is not applied after session restore. Both in dashboard and logger window.

Firefox 98.0a1, 1.40.9rc1, system and browser set to default theme (light).

You must be logged in to vote

1 reply

You mean when uBO's own pages are already opened as part of the session? If so, this is #1669.

The Click2Load text is not visible.

Add ||youtube.com/embed/$3p,frame,redirect=click2load.html
Visit this link
Click on the YouTube video

Result:

You must be logged in to vote

1 reply

A minor cosmetic issue - any chances for a slightly higher contrast between the background and the font in Picker's counter? Be it either a darker background or a darker (black?) font.

I know these haven't changed since the Light theme, but I think it's just a tad more difficult for the eye to adjust to white on light grey from the darker colors everywhere else than it is on the light theme. Though, I also did have trouble (on occasion) reading the numbers on there in the past (due to eye strain or wherever).

You must be logged in to vote

1 reply

Just thinking out loud here, but do you think using opacity for .synopsis in Settings was the best idea? It's not that bad on the Dark theme, but on Light, it kinda reads as "unimportant". At least to me. And considering one of the synopses is for the new "Advanced" section, that seems rather counterproductive...

Perhaps using font-style: italic instead of changing opacity would be better? (on both themes)

Also, not entirely related, but I was wondering if using 4 color variables for .info icons isn't a bit too much (and with opacity in the synopsis it looks like there's a 2nd shade of grey too)?
AFAIK, var(--info2-ink) is only used in the Trusted pane now + is less attention grabbing than var(--info3-ink), which seems to be only in the Advanced section synopsis. And I'm just wondering if the 3 different colored info icons .important, .very-important and .mustread do really need to be different if they're all on different tabs?
Personally, I'd probably stick with var(--info3-ink) / .very-important for them all.

You must be logged in to vote

2 replies

I use a lot this guide to make decisions, and this is the case here. It says medium emphasis should use text at opacity 60, and this is what I did. I checked the resulting color versus the background, and I get a AA+ contrast ratio, which means it passes the contrast test. I prefer to stick to the material design guide to make this sort of decision, otherwise every decision become subjective and as such candidate for endless debate because everybody has their own opinion when subjectivity is involved.

I see. I just figured I'd ask since the opacity is a new addition. Thanks for clarifying.

The shadows problems remain on 1.40.9rc1.

You must be logged in to vote

1 reply

I consider the shadow issue to be a long standing issue, I found it was problematic before as well, and I will need to research something which work better than using a text shadow regardless of theme. The context information is what helps distinguish tabless requests, their root context is always 0,....

You must be logged in to vote

7 replies

The browser is rendering these form widgets, the question is how come the browser does not make use of the dark theme for these? Surely the browser is better placed to know whether it should apply dark theme to these widget when perfers-color-scheme is set to dark.

I think this option is a hint for the browser, it says that the page supports dark/light schemes. If the page does not support them (normal) then the browser will not try to adjust the widgets.

What wonders me is that from the "Compatibility" section, it looks like the only supported value is color-scheme: light dark;???

Supported value is dark, light, light dark -- what is not supported is the modifier only.

.dark input, .dark select, .dark textarea { color-scheme: dark; }

Wouldn't that work?

Thanks for reminding me, I was planning to use color-scheme in the current dev cycle but forgot about this.

Theme set is "auto"

There's create button which was yellow when creating the filters,but now it is grey

Screenshot

is it by design now? if yes then doesn't look good

You must be logged in to vote

1 reply

The icon at the bottom of "my rules" is hard to see in dark mode. But to be fair, it's hard to see in light mode as well.

You must be logged in to vote

1 reply

Could --sf-keyword-ink be changed so that it stands out a bit more? At the moment it feels like it blend in too much with the others.

You must be logged in to vote

5 replies

Suggest a replacement color?

If you look edit history of this comment you can see that I originally had suggestion, but I edited it out because I thought that maybe it was too aggressive color. But something like that where it clearly stands out that there's asterisks in the url, for example.

What is the hex color code in your screenshot?

Your hue is ~308, the original is 280 -- so for the next dev build I will nudge the hue to 290 and wait for feedback.

Logger's #netFilteringDialog > .headers > .tools > span:hover is not theme specific, serving a light background on the dark theme.

You must be logged in to vote

1 reply

You must be logged in to vote

1 reply

The inherited ones are closer to the color of the ones without rules, so in the light theme they are lighter gray, in the dark theme they are darker gray. Same applies to the block/allow rules, the lightness of the color on inherited rules is between the lightness of the color of the rule and the default lightness of the background.

A very minor issue. In the logger, when on the "All" tab, the message about filter lists being reloaded is nearly invisible with its dark blue font color on a dark grey background.

gorhill/uBlock@ec8292e

You must be logged in to vote

0 replies