Chromium change:
https://source.chromium.org/chromium/chromium/src/+/f64b910afa793bde5f50bf88c5b584007ffc68bd
commit f64b910afa793bde5f50bf88c5b584007ffc68bd
Author: Alison Maher <almaher@microsoft.com>
Date: Tue Jan 5 17:02:46 2021 +0000
Refactor contrast tracking in NativeTheme
In CL:2412972, it was recommended to split out the concepts of high
contrast and forced colors mode inside NativeTheme. Doing so allows
us to remove the |is_high_contrast_| variable in favor of
|preferred_contrast_|. This also adds a |forced_colors_| variable
to distinguish these concepts.
I was planning to wait until https://github.com/w3c/csswg-drafts/issues/5433
had been resolved before making this refactor. However, this will
likely clean up other areas that will make things like a forced
colors devtools emulation cleaner to implement. This will be easy
enough to update once the above issue has been resolved (if needed).
_________________________________
To explain the distinction of high contrast/preferred contrast/forced
colors mode in a bit more detail:
- High contrast in most cases triggers a preferred contrast of "more".
- Since we are tracking the preferred contrast in NativeTheme, we can
remove the redundancy of also tracking if we are in high contrast.
- On Windows, high contrast is a bit different in that it also triggers
what we call forced colors mode. In forced colors mode, the preferred
contrast level may be "more" or "less" depending on which foreground
and background colors are being forced. Thus, we also need to track
the forced colors state in NativeTheme to detect cases of Windows
high contrast that are not considered more or less contrast, but some
contrast level in between.
_________________________________
This CL should not result in any functional changes.
Bug: 1157686,1107431
mkarolin
5036514d5c