Monochrome media query gives incorrect values |
||||||||||
Issue description<b>Version: <Kenneth, what is the frequency?></b> <b>OS: <please tell me it's not XP></b> What steps will reproduce the problem? (1) Set "Use Grayscale" in System Preferences -> Accessibility (2) Go to https://jsfiddle.net/sytuqzdw/1/ (3) Observe that it has a large border on Safari but not Chrome This is because Safari is using the CGDisplayUsesInvertedPolarity function to specify monochrome attributes, as per: https://github.com/WebKit/webkit/blob/master/Source/WebCore/platform/mac/PlatformScreenMac.mm We should match this
,
May 3 2017
This fell between the cracks.
,
May 3 2017
Given that this is still a real bug should we add a to-do somewhere in the code or maybe shrike@ or someone else on the Mac side could help fix it?
,
May 3 2017
ccameron@ - seems like we still want to do this. How much work are we talking about, and can you pick up where you left off with your work on it?
,
May 4 2017
Work estimation for an unknown problem is notoriously difficult. After a few hours digging back into this, there are at least 2 bugs here, neither of which are the one in the original report. The not-bug: Chrome uses CGDisplayUsesForceToGray while Safari uses CGDisplayUsesInvertedPolarity. This doesn't matter -- CGDisplayUsesForceToGray returns the correct value. First bug: We evaluate CGDisplayUsesForceToGray BuildDisplayForScreen, but never seem to re-evaluate it when accessibility settings change. Perhaps worth looking into sometime, I filed issue 718400. Second bug: I think that MonochromeMediaFeatureEval is computing the wrong value. The body of MonochromeMediaFeatureEval is: if (!media_values.MonochromeBitsPerComponent()) { if (value.IsValid()) { float number; return NumberValue(value, number) && CompareValue(0, static_cast<int>(number), op); } return false; } return ColorMediaFeatureEval(value, op, media_values); I have no idea what this does. I cargo-culted the code from ColorMediaFeatureEval, changing it to float number; int bits_per_component = media_values.MonochromeBitsPerComponent(); if (value.IsValid()) return NumberValue(value, number) && CompareValue(bits_per_component, static_cast<int>(number), op); return bits_per_component != 0; With this patch, the sample matches Safari.
,
May 4 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c9ef836bccf4a19fde92b42f6d68e8895f0a1a49 commit c9ef836bccf4a19fde92b42f6d68e8895f0a1a49 Author: ccameron <ccameron@chromium.org> Date: Thu May 04 21:26:41 2017 Change Monochrome media query evaluator Change this to match ColorMediaFeatureEval's behavior. Previously, this was incorrectly comparing the monochrome feature against color bit depth. BUG= 645697 Review-Url: https://codereview.chromium.org/2863603002 Cr-Commit-Position: refs/heads/master@{#469478} [modify] https://crrev.com/c9ef836bccf4a19fde92b42f6d68e8895f0a1a49/third_party/WebKit/Source/core/css/MediaQueryEvaluator.cpp [modify] https://crrev.com/c9ef836bccf4a19fde92b42f6d68e8895f0a1a49/third_party/WebKit/Source/core/css/MediaQueryEvaluatorTest.cpp
,
May 4 2017
,
May 11 2017
Tested this issue on latest Dev and seeing the same behavior in (60.0.3095.5- dev) with fix and (58.0.3029.110- Stable) without fix. Some how observing some other behavior in Safari Browser. Please find the Screenshot of Safari and Chrome @ccameron: Could you please confirm the behavior.
,
May 12 2017
,
May 12 2017
,
May 18 2017
That is probably because of issue 718400 -- we don't update accessibility settings as often as we should. I verified the issue is fixed on Canary, screenshot attached. |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by ccameron@chromium.org
, Sep 10 2016