Issue metadata
Sign in to add a comment
|
Patterns containing zero-area shapes are rendered incorrectly
Reported by
n...@noahveltman.com,
Feb 23 2018
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.167 Safari/537.36 Steps to reproduce the problem: 1. Load the attached file, or visit https://codepen.io/anon/pen/Zrjmqm What is the expected behavior? At least three relevant cases: 1. A <pattern> with a circle with a very small, non-zero radius (e.g. 0.0001) 2. A <pattern> with nothing in it 3. A <pattern> with a zero-radius circle or zero-area rectangle in it. The expected behavior of filling a <rect> with any of these patterns is an effectively transparent, unfilled rectangle. What went wrong? Filling a shape with #1 and #2 produces the expected result: no fill/transparent. Filling a shape with #3 causes Chromium to seemingly ignore the pattern fill and fall back to the default fill (black). Other browsers besides Chrome, and vector graphics software, show the expected behavior. Did this work before? Yes Unsure, but it worked as of the latest version in Fall 2016 Does this work in other browsers? Yes Chrome version: 64.0.3282.167 Channel: n/a OS Version: OS X 10.12.6 Flash Version:
,
Feb 26 2018
Able to reproduce the issue on reported chrome version 64.0.3282.167 and latest canary 66.0.3355.0 using Mac 10.12.6, Windows-10 hence providing Bisect Info Note: Issue is not seen in Ubuntu 14.04 Bisect Info: ================ Good build: 64.0.3271.0 Bad build: 64.0.3272.0 You are probably looking for a change made after 517611 (known good), but no later than 517612 (first known bad). https://chromium.googlesource.com/chromium/src/+log/c22227095c899aed65e70000d4c23370b06f69c1..6abc3144bdeabb9d6d965896f530d12e8c0481c4 Skia CL: https://skia.googlesource.com/skia.git/+log/3e4d1fde7fab..39631f3df172 Could anyone from the DEV team help in assigning it to the right owner. Adding ReleaseBlock-Stable as it is seems a recent break, feel free to remove it if not applicable. Thanks!
,
Feb 26 2018
Guessing 0d96175c97856d272d299c86577a34f825e810fc
,
Feb 26 2018
,
Feb 27 2018
,
Feb 27 2018
M65 Stable promotion is coming VERY soon next week. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. Thank you.
,
Feb 27 2018
We've committed the revert of the problematic CL yesterday: https://skia-review.googlesource.com/c/skia/+/110200 Can you please check if the issue has been resolved?
,
Feb 27 2018
Tested on ToT, the revert fixed this issue.
,
Feb 27 2018
[Auto-generated comment by a script] We noticed that this issue is targeted for M-65; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-65 label, otherwise remove Merge-TBD label. Thanks.
,
Feb 27 2018
fmalita@, could you pls verify this on latest canary version 66.0.3356.0?
,
Feb 27 2018
Also revert listed at #7 will be safe to merge to M65? OR can we wait until M66 as this was regressed in M64 stable?
,
Feb 27 2018
@govind verified - 66.0.3356.0 has the fix.
,
Feb 27 2018
I believe that it's safe to merge as the change is very minimal
,
Feb 27 2018
This bug requires manual review: We are only 6 days from stable. Please contact the milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 27 2018
Approving merge to M65 branch for revert listed at #7 based on comments #12 and #13. Please merge ASAP. Thank you.
,
Feb 27 2018
,
Feb 27 2018
This is already merged to M65 at #16. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by susan.boorgula@chromium.org
, Feb 25 2018