[SVG] SVG width and height computed styles return wrong values
Reported by
kari.pih...@gmail.com,
Oct 8 2017
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3235.0 Safari/537.36 Steps to reproduce the problem: 1. Open the attached width-height.svg 2. Open the developer tool Console 3. Observe the output What is the expected behavior? All computed styles printed in Console should be pixel values. As a reference, strokeWidth works as expected in Chrome and returns a pixel value. What went wrong? The width and height properties always return "auto": Computed style width: auto (expected 50px) Computed style height: auto (expected 50px) Computed style strokeWidth: 5px (expected 5px) --- after animation: Computed style width: auto (expected 100px) Computed style height: auto (expected 100px) Computed style strokeWidth: 20px (expected 20px) Did this work before? No Does this work in other browsers? N/A Chrome version: 63.0.3235.0 Channel: canary OS Version: OS X 10.12.6 Flash Version: Safari displays the computed values correctly: [Safari] Computed style width: 50px (expected 50px) [Safari] Computed style height: 50px (expected 50px) [Safari] Computed style strokeWidth: 5px (expected 5px) [Safari] --- after animation: [Safari] Computed style width: 100px (expected 100px) [Safari] Computed style height: 100px (expected 100px) [Safari] Computed style strokeWidth: 20px (expected 20px) This bug is related to https://bugs.chromium.org/p/chromium/issues/detail?id=400725
,
Oct 8 2017
(Note to future self: Looks like the animation code applies zoom to stroke-width although it shouldn't - strokeWidth computes to 40px on my 2x HiDPI system...)
,
Oct 9 2017
,
Oct 26 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4531dfc9b26fa49e93c76f2168ee35e7e00783f0 commit 4531dfc9b26fa49e93c76f2168ee35e7e00783f0 Author: Fredrik Söderquist <fs@opera.com> Date: Thu Oct 26 16:45:46 2017 Rework computed style handling for 'width' and 'height' getComputedStyle(...) for 'width' and 'height' would always return 'auto' for layout objects to which said property did not "apply" (by some fuzzy heuristic.) This specifically broke for some SVG elements where 'width' and 'height' apply (<rect>, <image> and <foreignObject>), but is also wrong more generally - per CSSOM [1]. Rework the relevant parts of ComputedStyleCSSValueMapping::Get to consider if the used value or the computed value should be used for the respective property. The new helper (WidthOrHeightShouldReturnUsedValue) replaces the old WidthOrHeightPropertyAppliesToObject, while removing the explicit return of an 'auto' identifier. 'auto' (or any other computed value) will now be returned via ZoomAdjustedPixelValueForLength if the resolved value is not the used value. This is a behavioral change, and matches the behavior of Gecko. Fold the old svg/css/getComputedStyle-svg-text-width-height.html test into a new one that cover more (SVG) cases. [1] https://drafts.csswg.org/cssom/#resolved-value Bug: 708888 , 772707 Change-Id: I573362a03c9e0d98251bdbcf4e9854a5a5d8dd67 Reviewed-on: https://chromium-review.googlesource.com/707103 Reviewed-by: Philip Rogers <pdr@chromium.org> Reviewed-by: Stephen Chenney <schenney@chromium.org> Commit-Queue: Fredrik Söderquist <fs@opera.com> Cr-Commit-Position: refs/heads/master@{#511848} [modify] https://crrev.com/4531dfc9b26fa49e93c76f2168ee35e7e00783f0/third_party/WebKit/LayoutTests/external/wpt/html/semantics/embedded-content/the-object-element/object-attributes-expected.txt [modify] https://crrev.com/4531dfc9b26fa49e93c76f2168ee35e7e00783f0/third_party/WebKit/LayoutTests/fast/css/getComputedStyle/getComputedStyle-resolved-values-expected.txt [modify] https://crrev.com/4531dfc9b26fa49e93c76f2168ee35e7e00783f0/third_party/WebKit/LayoutTests/fast/css/getComputedStyle/getComputedStyle-with-pseudo-element-expected.txt [modify] https://crrev.com/4531dfc9b26fa49e93c76f2168ee35e7e00783f0/third_party/WebKit/LayoutTests/fast/css/getComputedStyle/getComputedStyle-with-pseudo-element.html [modify] https://crrev.com/4531dfc9b26fa49e93c76f2168ee35e7e00783f0/third_party/WebKit/LayoutTests/inspector-protocol/dom-snapshot/dom-snapshot-getSnapshot-expected.txt [modify] https://crrev.com/4531dfc9b26fa49e93c76f2168ee35e7e00783f0/third_party/WebKit/LayoutTests/svg/css/getComputedStyle-listing-expected.txt [delete] https://crrev.com/a750f6b5df4c79c4673e472d1c9b8911a1e68282/third_party/WebKit/LayoutTests/svg/css/getComputedStyle-svg-text-width-height.html [add] https://crrev.com/4531dfc9b26fa49e93c76f2168ee35e7e00783f0/third_party/WebKit/LayoutTests/svg/css/getcomputedstyle-width-height.html [modify] https://crrev.com/4531dfc9b26fa49e93c76f2168ee35e7e00783f0/third_party/WebKit/Source/core/css/ComputedStyleCSSValueMapping.cpp
,
Feb 16 2018
Has this patch gone live? Because I'm still seeing the problem on elements with SVG layout, even in Canary. My test case: https://codepen.io/AmeliaBR/pen/EQbmmP?editors=1011 Output in Version 66.0.3348.0 (Official Build) canary (64-bit) (and also in stable): "a" "556.5px" "64px" "b" "auto" "auto" "c" "100%" "64px" The SVG "a" has CSS box layout, while "b" and "c" have SVG layout. "a" acts as expected, with % and em converted to pixels. "b" uses width/height attributes, and these aren't being reflected in the computed style at all. "c" uses width/height style properties, and the basic computed values are given, not the resolved values converted to px.
,
Feb 16 2018
No, the change to resolve to px has not been made yet (which is why this bug is still open.) The patch/CL landed above was merely a step on the way.
,
Dec 13
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/269ecd52bd4e0ec15a70924b089589f9bfe26ee0 commit 269ecd52bd4e0ec15a70924b089589f9bfe26ee0 Author: Fredrik Söderquist <fs@opera.com> Date: Thu Dec 13 17:11:33 2018 Return used width/height for SVG <image>, <rect> and <foreignObject> Per https://drafts.csswg.org/cssom/#resolved-values we should return the "used value" for 'width' and 'height' on these elements [1]. This behavior was clarified in SVGWG GitHub issue #349 [2]. [1] And also on <svg>, but we don't support those properties there yet. Tests added for that case too though. [2] https://github.com/w3c/svgwg/issues/349 Bug: 772707 Change-Id: Ic7b6b148883d4380daadb41b62bddd02da55e1af Reviewed-on: https://chromium-review.googlesource.com/c/1374291 Reviewed-by: Philip Rogers <pdr@chromium.org> Commit-Queue: Fredrik Söderquist <fs@opera.com> Cr-Commit-Position: refs/heads/master@{#616343} [modify] https://crrev.com/269ecd52bd4e0ec15a70924b089589f9bfe26ee0/third_party/blink/renderer/core/css/properties/computed_style_utils.cc [modify] https://crrev.com/269ecd52bd4e0ec15a70924b089589f9bfe26ee0/third_party/blink/renderer/core/css/properties/computed_style_utils.h [modify] https://crrev.com/269ecd52bd4e0ec15a70924b089589f9bfe26ee0/third_party/blink/renderer/core/css/properties/longhands/height_custom.cc [modify] https://crrev.com/269ecd52bd4e0ec15a70924b089589f9bfe26ee0/third_party/blink/renderer/core/css/properties/longhands/width_custom.cc [modify] https://crrev.com/269ecd52bd4e0ec15a70924b089589f9bfe26ee0/third_party/blink/web_tests/external/wpt/svg/extensibility/foreignObject/properties.svg [add] https://crrev.com/269ecd52bd4e0ec15a70924b089589f9bfe26ee0/third_party/blink/web_tests/external/wpt/svg/geometry/parsing/height-computed-expected.txt [add] https://crrev.com/269ecd52bd4e0ec15a70924b089589f9bfe26ee0/third_party/blink/web_tests/external/wpt/svg/geometry/parsing/height-computed.svg [add] https://crrev.com/269ecd52bd4e0ec15a70924b089589f9bfe26ee0/third_party/blink/web_tests/external/wpt/svg/geometry/parsing/width-computed-expected.txt [add] https://crrev.com/269ecd52bd4e0ec15a70924b089589f9bfe26ee0/third_party/blink/web_tests/external/wpt/svg/geometry/parsing/width-computed.svg [delete] https://crrev.com/419c4bfbfb94849ed30dcab7c3aaf67afe238b27/third_party/blink/web_tests/svg/css/getcomputedstyle-width-height.html
,
Dec 13
|
|||
►
Sign in to add a comment |
|||
Comment 1 by f...@opera.com
, Oct 8 2017Status: Available (was: Unconfirmed)