Systematically (but apparently randomly) fails to render SVG nodes at certain rotations when inside many nested transforms
Reported by
teo8...@gmail.com,
Dec 10 2017
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36 Example URL: http://jsbin.com/wotakejuta/1/edit?html,console,output Steps to reproduce the problem: 1. visit http://jsbin.com/wotakejuta/1/edit?html,console,output What is the expected behavior? You should see a red-stroke no-fill square rotating at a roughly constant speed around its center. What went wrong? When the rotation goes within certain ranges, the square disappears, for no reason. The javascript animates the rotation just to demonstrate that certain values reproduce the issue while others don't, but you can remove the script and reproduce the issue or not by just manually changing the rotation value. The rotation is applied to the innermost <g> node that wraps the rect node within a deep tree of many <g>s with opposite transforms cancelling each other out resulting in an identity transform. Removing a couple of levels in the tree will make the issue disappear. If there is a valid reason for having a maximum allowed depth in an svg tree and that prevents the content for being rendered properly, you should print an error in the console when the maximum allowed depth is exceeded. Silently dropping or failing to display random nodes is not acceptable. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 62.0.3202.94 Channel: n/a OS Version: Flash Version:
,
Dec 11 2017
I'd suspect what happens is that a FloatRect -> IntRect conversion somewhere (SVGLayoutSupport::TransformVisualRect would be my immediate guess) overflows and thus turns the resulting rect "inside out", making it appear empty.
,
Dec 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/663b023cf7022eca119acc1b8b3a610cd8993da3 commit 663b023cf7022eca119acc1b8b3a610cd8993da3 Author: Fredrik Söderquist <fs@opera.com> Date: Thu Dec 21 21:39:26 2017 [PE] Avoid integer overflows in EnclosingIntRect(const FloatRect&) The size computation could potentially overflow, yielding an "empty" result, which could have different consequences depending on the user. In CullRect::UpdateCullRect for instance, the MapRect call could make the cull rectangle appear empty causing visible elements to be culled. Rather than using integers for the computing the enclosing rect, use floats, and then cast that to an IntRect at the end. (The IntRect(const FloatRect&) constructor clamps the input using clampTo.) Adjust EnclosedIntRect similarly because it shares the same deficiency. Bug: 793676 Change-Id: I63bcff3747dea7f29dac39a05d9cf179b0770030 Reviewed-on: https://chromium-review.googlesource.com/839521 Commit-Queue: Fredrik Söderquist <fs@opera.com> Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> Cr-Commit-Position: refs/heads/master@{#525812} [modify] https://crrev.com/663b023cf7022eca119acc1b8b3a610cd8993da3/third_party/WebKit/Source/platform/geometry/FloatRect.cpp [modify] https://crrev.com/663b023cf7022eca119acc1b8b3a610cd8993da3/third_party/WebKit/Source/platform/geometry/FloatRect.h [modify] https://crrev.com/663b023cf7022eca119acc1b8b3a610cd8993da3/third_party/WebKit/Source/platform/geometry/FloatRectTest.cpp [modify] https://crrev.com/663b023cf7022eca119acc1b8b3a610cd8993da3/third_party/WebKit/Source/platform/geometry/FloatSize.h
,
Dec 22 2017
|
|||
►
Sign in to add a comment |
|||
Comment 1 by kochi@chromium.org
, Dec 11 2017