You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Accessibility issue, especially for long pages where scroll bars tend to be more useful than the scroll wheel or function keys. It is also not possible to quickly tell where you're at in the web page.
Expected visual
The scroll bar to have a contrast no worse than Windows 10's light theme scroll bars and Discord's dark theme scrollbars for the chat on the desktop client, which can already be borderline impossible to see at a glance.
Actual visual
The scroll bar's contrast ratio is too poor to be able to tell where the scrollbar thumb is within a second of looking at it on a fair amount of displays, making it impossible to use effectively when you need it.
KDE Plasma ~5.26.3 (uptime of 88 days with updates makes this uncertain) on Arch Linux with Linux 5.19.11-arch1-1 active. This is unlikely to matter to how Chromium renders the scrollbar, as it's using the CSS scrollbar rather than native.
At the time of noticing this, Redshift was active with a 3250K colour temperature and 80% brightness on top of the minimum brightness of both displays, which tends to amplify any low contrast issues such as this.
This cannot be reproduced on Firefox for as it doesn't implement any hooks for the webpage to override the scrollbar, instead electing to always render its own, as either an overlay, GTK's, or Windows'.
I have not yet started Chromium with only force dark to verify that the WebContentsForceDark (chrome://flags/#enable-force-dark) flag set to Selective inversion of select non-image elements is causing the poor contrast of the scrollbar.
I have also not yet tested to see if the light theme scrollbar of the webpage similarly has a poor contrast ratio yet.
The text was updated successfully, but these errors were encountered:
Weird, the scrollbar is white for me on firefox and turns darker if I switch to light mode
I've acknowledged that with:
This cannot be reproduced on Firefox for as it doesn't implement any hooks for the webpage to override the scrollbar, instead electing to always render its own, as either an overlay, GTK's, or Windows'.
Firefox will use its own scrollbar on any page, as it doesn't read the CSS that Chromium (and by extension, practically all common browsers minus Firefox) does.
I have the inverse: Dark mode contrasts fine, but light mode is basically invisible. I don't know why there even is a custom scroll bar, I for one much prefer my system scrollbar.
Why?
Accessibility issue, especially for long pages where scroll bars tend to be more useful than the scroll wheel or function keys. It is also not possible to quickly tell where you're at in the web page.
Expected visual
The scroll bar to have a contrast no worse than Windows 10's light theme scroll bars and Discord's dark theme scrollbars for the chat on the desktop client, which can already be borderline impossible to see at a glance.
Actual visual
The scroll bar's contrast ratio is too poor to be able to tell where the scrollbar thumb is within a second of looking at it on a fair amount of displays, making it impossible to use effectively when you need it.
Scrollbar
Extra notes:
Ungoogled Chromium
105.0.5195.125 (Official Build, ungoogled-chromium) Arch Linux (64-bit)
Active flags:
/usr/lib/chromium/chromium --force-dark-mode --enable-features=OverlayScrollbar --force-dark-mode --enable-features=OverlayScrollbar --disable-features=GlobalMediaControls --enable-crashpad --flag-switches-begin --bookmark-bar-ntp=never --blink-settings=disallowFetchForDocWrittenScriptsInMainFrame=true --extension-mime-request-handling=always-prompt-for-install --keep-old-history --ozone-platform-hint=auto --scroll-tabs=always --enable-features=OverlayScrollbar,CopyLinkToText,GlobalMediaControlsModernUI,ParallelDownloading,ReaderMode,TabSearchMediaTabs:Also+show+Media+Tabs+in+Open+Tabs+Section/true,UseDownloadOfflineContentProvider,VaapiVideoDecoder,WebContentsForceDark:inversion_method/cielab_based/image_behavior/none/foreground_lightness_threshold/150/background_lightness_threshold/205,WebRtcHideLocalIpsWithMdns,WebRtcHybridAgc --disable-features=GlobalMediaControls,ClearDataOnExit,LiveCaption,MediaSessionWebRTC,WebRtcAnalogAgcClippingControl --flag-switches-end --ozone-platform=x11
KDE Plasma ~5.26.3 (uptime of 88 days with updates makes this uncertain) on Arch Linux with Linux 5.19.11-arch1-1 active. This is unlikely to matter to how Chromium renders the scrollbar, as it's using the CSS scrollbar rather than native.
At the time of noticing this, Redshift was active with a 3250K colour temperature and 80% brightness on top of the minimum brightness of both displays, which tends to amplify any low contrast issues such as this.
This cannot be reproduced on Firefox for as it doesn't implement any hooks for the webpage to override the scrollbar, instead electing to always render its own, as either an overlay, GTK's, or Windows'.
I have not yet started Chromium with only force dark to verify that the
WebContentsForceDark
(chrome://flags/#enable-force-dark
) flag set toSelective inversion of select non-image elements
is causing the poor contrast of the scrollbar.I have also not yet tested to see if the light theme scrollbar of the webpage similarly has a poor contrast ratio yet.
The text was updated successfully, but these errors were encountered: