dark mode API & setting for chrome.google.com/webstore/ & chrome://<chrome-page/extension-page>
Reported by
wesam.we...@gmail.com,
Nov 12 2017
|
|||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.89 Safari/537.36 Steps to reproduce the problem: 1. install some Dark mode extension and set dark mode on. 2. visit chrome.google.com/webstore/ or any chrome page like Downloads, settings or other extensions' pages which include the extension's options page. 3. extension won't (can't) work on these pages, other than that extension works perfectly. What is the expected behavior? when you visit a page that a extension can't access. it should be dark or other modes (inverted colors etc), Chrome should implement these modes and provide an API that extensions can use, Chrome's pages and extensions' pages look should change according to settings set by the API. so when the user visits Chrome://version , settings, extensions, downloads, any of the other Chrome pages or any extensions page, the user should see what they expect (UX), and not wonder and be annoyed why the extension is not working on these pages, even worse submit a low rating because "it doesn't work on all pages". What went wrong? Chrome's pages, Chrome webstore and other extensions pages are not dark even though user has a (dark/inverted) mode extension installed and on. so when the user visits Chrome://version , settings, extensions, downloads and the other Chrome pages, the user should see what they expect, and not wonder and be annoyed why the extension is not working on these pages, even worse submit a low rating because "it doesn't work on all pages". WebStore page: Chrome web store Did this work before? N/A Chrome version: 62.0.3202.89 Channel: stable OS Version: 10.0 Flash Version: this is not a feature request for me and the other late night owl hackers, it's just a small feature for better user experience (UX) (the general user's).
,
Nov 13 2017
this is also a accessibility feature, Google is a exceptional company with accessibility support for all of its products (GSuite etc), with accessibility teams and board at Google https://www.google.com/accessibility/. Firefox and Edge on windows support high contrast mode, all the pages including the browser's pages (which aren't accessible to extensions),are in high contrast when high contrast mode is ON, on Windows. other browsers change title bar, browser pages and browsing pages appearance in high contrast mode, Chrome shows a popup just after it detects that you set high contrast mode on, recommending that you install a dark or high contrast theme and a dark/high-contrast mode extension from the Chrome web store, which is the better approach in my opinion, because it enables more customizabily,you're not confined to the browser vendor's implementation of a high-contrast/dark mode, and better for browser vendors too, less code to maintain according to users preferences (less bug reports). should Chrome change the browser's pages (setting,Downloads etc.) appearance to the installed theme's dominant colors, if there's any? but themes are images, I don't know if there's fields in manifest.json for the colors of the theme.
,
Nov 17 2017
For security reasons, I don't think we can let extensions run on these pages. But we should have an accessibility story for it. dmazzoni@, can you help triage this from an a11y perspective?
,
Nov 17 2017
oh just found out that you've been working on native high contrast mode. I'm aware of the security issues with letting extensions access these pages, I mentioned that above. what about other modes than high contrast for a11y, Dark mode and high contrast mode are not the same thing, the extension I use Doesn't change font colors, can there be degrees of customization, similar to Windows's (see attached screenshot) in addition to toggles to what can't be changed [x] don't change font colors (checkbox under a11y section in settings page), or 4 states for each setting/variable, with toggle boxes () default () from OS (0) Custom (with input/colorpicker to set value) () from extension [Drop down menu for installed extension with theming/a11y permission], make these settings/variables accessible with a chrome extension API, selected extension only is allowed to set values, and you have performant, a11y and general page theming/moding solution. first time high contrast/a11y mode is set ON, on Windows, initialize these setting values/variables with Windows's/OS's equivalent High contrast settings (see attached screenshot), this is a the Settings UWP UI, behind it is the personlization engine which includes themes going back to Windows Vista, I believe there are API's that Windows provides to read and even set, nonetheless, I have seen and used methods to change Window's look that with Registery editing (you are only reading the values so it's OK to use Registery), I don't think they'll be at the same location in the registery going back to Windows Vista, though Microsoft's backwards compatibility story (with API's at least) on Windows is remarkable. I have also noticed the issues/limitation with the page theming extensions mentioned in the high contrast issue id=685242, and started thinking of fixes for a fork I was planning to build and publish. "* Doesn't work on web store or Chrome WebUI pages * Incompatible with some web sites due to CSS injected in page conflicting with existing page CSS * Exposes bugs in CSS filters * Flickers as page loads sometimes"
,
Nov 18 2017
sorry can't edit the comment above,
The "[x] don't change font colors" checkbox have the same effect as the
"() default" in the toggle box array I mentioned after.
forgot to edit it out.
extensions with a11y permission are required to provides *.css file in manifest.json, see the snippet from manifist.json below.
only a subset of css is allowed (this is be easily implemented, CSS/CSS3+ features that can compromise security aren't allowed,
animations, transformations, etc. are not allowed,
the CSS subset should include only standard HTML element name selectors, like p { } or label { }.
no, class selectors (.nav {}) or id selectors #nav {}, because this is not a "userstyle"* solution,
and the styles will be applied on every page, there are "userstyle" extensions for that on the chrome store.
you can also not allow styles that can radically change pages.
this is can be enforced by adding a block to the publishing pipeline for a11y extensions that can do static analysis and maybe even dynamic analysis/testing.
JS in CSS is only allowed on old IE browsers [0], nonetheless, it's not allowed anyways (not part of the subset).
checkout also this question on SE [1],
this can be optimized to be much faster than the methods used by extensions, CSS or JS injection, i'm sure there are more ways I can't think of/can't imagine right now too.
{
"a11y": {
"stylesfile": "darkMode.css"
}
}
[0] https://stackoverflow.com/questions/476276/using-javascript-in-css/482088#482088
[1] https://security.stackexchange.com/questions/37832/css-based-attacks
* "userstyle", as opposed to "userscript"
https://chrome.google.com/webstore/detail/stylish-custom-themes-for/fjnbnpbmkenffdnngjfgmeleoegfcffe?hl=en
https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo?hl=en
,
Nov 29 2017
looking forward to at least some feedback, guys. ;,/
,
Dec 9 2017
|
|||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||
Comment 1 by divya.pa...@techmahindra.com
, Nov 13 2017Labels: Triaged-ET M-64 Needs-Triage-M62 OS-Linux OS-Mac
Status: Untriaged (was: Unconfirmed)