Issue metadata
Sign in to add a comment
|
Highlighted web contents text is not sufficiently visible when the background color matches the highlight color |
||||||||||||||||||||||
Issue descriptionChrome Version: 66.x OS: Linux, but probably all What steps will reproduce the problem? (1) Load attached text.html. It's a slightly modified version of a standard accessibility test, with the addition of white text on blue background. (2) Highlight all the text on the page. (e.g. press ctrl + a) What is the expected result? All the highlighted text should appear highlighted with sufficient contrast. What happens instead? Some text does not appear highlighted. See attached chromium_firefox.png screenshot. The image contains 3 different results: - Chromium with the default theme. => The white text on blue background does not appear highlighted. It looks the same as when it is unhighlighted. - Chromium on Linux using a GTK theme. The GTK theme is set on a computer running Cinnamon. In the Control Center: Themes > Controls = Blackbird => The white text on baclk background does not appear highlighted. It looks the same as when it is unhighlighted. - Firefox with the default theme. => The white text on blue background has been inverted so it appears differently from when the line is not highlighted.
,
Sep 15
Emil, could you weigh in and assign back to me? One thing that's interesting is that Firefox does have this behavior on Linux and Windows but not on macOS. Here's my guess as to the algorithm Firefox uses when drawing selected text, based on playing around with that example. 1. The selection color, the background color, and the text color are all classified as either "dark" or "light", probably by thresholding the brightness. 2. If the selection color and background color are the same classification (both dark or both light), the selected background becomes black if the background was light, and white if the background was dark. Otherwise the background color is unchanged. 3. If the text color and new computed background color are both dark, - The new text color is the highlight color if it's light, otherwise white. If the text color and new computed background color are both light, - The new text color is the highlight color if it's dark, otherwise black. If the text color and new computed background are not the same classification, - The text color is unchanged. This needs more investigation to confirm this algorithm, but if I'm right, do we want to do something similar? Emil, I saw that you touched the selection_painting_utils.cc code recently. Would this be an appropriate place to implement this algorithm? Would we want to? UI Review? Who else should I loop in? Please reassign back to me, thanks.
,
Dec 13
The right place to do this would indeed be in selection painting code. We have logic for inverting the selection background color if it's the same as the text color but nothing that adjusts it based on the non-selected color/background of the element. If a page author specifies a color/background that is identical to the selection color/background then the assumption has been that they would either also specify the desired selection colors or that they don't want selections to differ in style. That assumption might not be correct and the behavior in Firefox is arguably better. From some quick testing it appears that they flip the selection text and background colors if the difference between the selected and non-selected color is closer than a certain threshold. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by dmazz...@chromium.org
, Sep 7