@media (min-width: 100vw) doesn't always match
Reported by
cvreb...@gmail.com,
Apr 18 2016
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36 Steps to reproduce the problem: 1. Open the attached testcase in Chrome 2. While looking at the green bar, horizontally resize the window back and forth. What is the expected behavior? @media (min-width: 100vw) is a tautology (the viewport's width is always at least 100% of the viewport's width), and thus should always match, thus always making the bar green. What went wrong? At certain widths, the media query doesn't match for some reason, causing the bar to turn red. Did this work before? N/A Chrome version: 52.0.2710.0 Channel: canary OS Version: OS X 10.11.4 Flash Version: Shockwave Flash 21.0 r0 Firefox and Safari behave as expected and don't suffer from this bug.
,
Apr 18 2016
confirmed; I'm not sure if this is a CSS issue or a painting issue, though.
,
Apr 19 2016
,
Apr 19 2016
This is a double precision issue in MediaValues::computeLengthImpl(). One example is when the width is 821. We first divide the viewport width by 100.0 to find a factor to multiply the value in the media query with. We divide 821/100.0, but 8.21 does not have an accurate representation for double precision. We end up with a min-width value of 821,00000000000011 which is greater than 821. Multiplying before dividing would have worked better in this case.
,
Apr 20 2016
Thanks for analyzing this issue! :) Patch to fix it is at https://codereview.chromium.org/1904523002/
,
Apr 20 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ee8bfd6290293a1b5dbf0813b6b3987f0e1ca545 commit ee8bfd6290293a1b5dbf0813b6b3987f0e1ca545 Author: yoav <yoav@yoav.ws> Date: Wed Apr 20 11:18:31 2016 Fix double comparisons for Media Queries Media queries that require double-based length comparisons weren't handled correctly. As a result, some media queries weren't matching when they should have. This CL fixes this issue by: * Performing the length calculation in a more double-friendly way, by multiplying before dividing rather than the other way around. * Apply a certain precision to length calculations, so that we could compare double equality. BUG= 604289 Review URL: https://codereview.chromium.org/1904523002 Cr-Commit-Position: refs/heads/master@{#388464} [modify] https://crrev.com/ee8bfd6290293a1b5dbf0813b6b3987f0e1ca545/third_party/WebKit/Source/core/css/MediaQueryEvaluator.cpp [modify] https://crrev.com/ee8bfd6290293a1b5dbf0813b6b3987f0e1ca545/third_party/WebKit/Source/core/css/MediaQueryEvaluatorTest.cpp [modify] https://crrev.com/ee8bfd6290293a1b5dbf0813b6b3987f0e1ca545/third_party/WebKit/Source/core/css/MediaValues.cpp [modify] https://crrev.com/ee8bfd6290293a1b5dbf0813b6b3987f0e1ca545/third_party/WebKit/Source/core/css/MediaValuesTest.cpp
,
Apr 20 2016
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by erikc...@chromium.org
, Apr 18 2016