77020 2012-01-25 09:48:07 -0800 [Qt]: SVG Bounding boxes are wrong for zero-length subpaths 2014-02-03 03:19:49 -0800 1 1 1 Unclassified WebKit SVG 528+ (Nightly build) Unspecified Unspecified RESOLVED INVALID P2 Normal --- 77964 1 schenney webkit-unassigned kadam kbalazs webkit-sed zimmermann oldest_to_newest 542376 0 schenney 2012-01-25 09:48:07 -0800 The bounding rectangles for zero length paths are not right when shown in LayoutTest results. They may or may not be correct at runtime when used for clipping etc. THis needs further investigation. Not that inconsistency in the reported bounds was present before the fix for 71820 was put in. This is an area that has been odd for quite some time. 542396 1 kbalazs 2012-01-25 10:05:05 -0800 Skipped tests on Qt: http://trac.webkit.org/changeset/105889 We should unskip them after fix. 543343 2 schenney 2012-01-26 11:55:02 -0800 The problematic test cases are: LayoutTests/svg/W3C-SVG-1.1-SE/painting-control-04-f.svg LayoutTests/svg/custom/zero-path-square-cap-rendering.svg LayoutTests/svg/stroke/zero-length-arc-linecaps-rendering.svg and probably LayoutTests/svg/stroke/* The problem appears to be due to the interaction between platform/gaphics/qt/PathQt.cpp and RenderSVGShape::updateCachedBoundaries(). The underlying behavior of Qt's QPainterPath implementation may be to blame. Regardless, this issue seems to be Qt only. Not Chromium or Mac. Working through RenderSVGShape::updateCachedBoundaries() for the second path element, looking at how it computes m_repaintBoundingBox, which is the thing reported by DumpRenderTree: - The paths in question should not be empty, and according to comments in PathQt.cpp, they will not be. The comment may be incorrect. - The path should be detected as being of zero subpath length, triggering the uniting of the (initially zero sized bound) with the zero length stroke rectangle bound. Check that the offending paths actually have been detected as zero length. - Then marker bounds are added, which cannot make the path smaller, so probably is not the issue. - Then the repaint rect is set, which should be the zero-length-stroke bound size. - The only other way it could go wrong is if the resources intersection decides it has a zero sized clip or something. Hope that helps whomever comes to look at this. 738994 3 kadam 2012-10-10 08:51:53 -0700 Is Anybody working this bug? 975389 4 jturcotte 2014-02-03 03:19:49 -0800 === Bulk closing of Qt bugs === If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it and remove [Qt] from the summary. If you believe that this is still an important QtWebKit bug, please fill a new report at https://bugreports.qt-project.org and add a link to this issue. See http://qt-project.org/wiki/ReportingBugsInQt for additional guidelines.