New issue
Advanced search Search tips

Issue 914324 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Size of SVG DOM element can be expanded by setting a larger svg-element inside it.

Reported by haldorm...@gmail.com, Dec 12

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.80 Safari/537.36

Steps to reproduce the problem:
1. Open the attached file in chrome and read values in alert.
2. Open the attached file in firefox and read values in alert.

What is the expected behavior?
When you set an svg's viewport with size/height attributes the SVG DOM element should have it's size set to this value until you explicitly change it's size.

What went wrong?
The SVG DOM element changes size based on it's children element's size and position. In my example there is a parent with 200px width and 70px height, then if an svg inherits it's size but has a line that is 500px wide and one that is 500px tall the SVG DOM element ignores it's own size attributes.

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 71.0.3578.80  Channel: stable
OS Version: 10.0
Flash Version: 

It is rendering correctly, the issue is with some functions that handle the size of the element. If you inspect it in chrome you will see that svg3 is 500/500, when you call getBoundingClientRect as seen in the alerts it returns this size. 

If you set a rect element inside the SVG to 100% width and height the rect's size is set as you would expect if this was not an issue. The issue is with the SVG itself.
 
svgsize.html
1.0 KB View Download
Status: Available (was: Unconfirmed)
This is not well specified...

CSSOM View says this for getClientRects() [1] (from which getBoundingClientRect() derives):

 "If the element has an associated SVG layout box return a DOMRectList object containing
  a single DOMRect object that describes the bounding box of the element as defined by
  the SVG specification, applying the transforms that apply to the element and its
  ancestors."

but it doesn't say _which_ bounding box that is. SVG 2 defines several, and for '<svg>' (a container element) it says [2].

So, Blink currently returns the bounding box with 'fill: true' (per the algorithm), while Gecko seems to always return the viewport for the inner SVG.

If we were to use 'clipped' bounding boxes that would just happen to yield the "correct" (expected) value because the descendants of #svg3 span start at 0,0. (Gecko doesn't appear to even consider the descendants here though.)

We have an open issue [3] on the spec for clarifying what the bounding box should be, and I think that was leaning towards "decorated bounding box", which wouldn't include clipping. (Issue 529734 is related to that, and it seems likely we'd merge this with that.)

[1] https://drafts.csswg.org/cssom-view/#dom-element-getclientrects
[2] https://svgwg.org/svg2-draft/coords.html#ContainerElementBoudingBoxComputation
[3] https://github.com/w3c/svgwg/issues/339
Labels: -OS-Windows
FWIW Chrome used to size it just like FF does now.
Bisected to r118158 WebKit roll - landed in 18.0.1012.0
https://trac.webkit.org/log/webkit/?rev=105305&stop_rev=105229

Not sure if this is the right place to mention it, but what you end up with by doing it this way is that you could have an svg, and a direct child rect element with 100% width and 100% height, and they do not have to be the same size. The fact that the % size set in children respects a different bounding box than the getBoundingClientRect and getBBox is hard to work around as a developer.
Even funnier, Firefox used to size it like Chrome does now. We accepted that was a bug https://bugzilla.mozilla.org/show_bug.cgi?id=530985 and fixed it.

FWIW I grant Chrome permission to use any tests I wrote in that bug in whatever way they require.

Sign in to add a comment