Bug 211282 – getBBox on tspan returns bbox for the containing text element

• Status: NEW
• Component: SVG

[fabswt]

Created attachment 398172 [details]
Demo of the issue, open the Console and check the dimensions output there

EXPECTED BEHAVIOR:
- When using an SVG element's getBBox() method, the browser should return the correct dimensions of the bounding box for <tspan> elements.

OBSERVED BEHAVIOR:
- The browser is returning the bounding box of its parent <text> element instead. i.e. all tspans return the dimensions of their parent element in place of their own real dimensions.

OTHER BROWSERS:
- This works fine in Firefox.
- Chromium had the same bug and fixed it recently: https://bugs.chromium.org/p/chromium/issues/detail?id=349835 (OK in Chromium Version 84.0.4133.0 (Developer Build) (64-bit); still not OK in Chrome Version 81.0.4044.129 (Official Build) (64-bit).)

Interestingly enough, unlike getBBox(), Safari's Inspector does return the correct dimensions (rounded), so a way to fetch the correct value might already be in the codebase.


Attaching a demo of my own; the Chromium thread has plenty of other examples if needed.

[Radar WebKit Bug Importer]

<rdar://problem/62735569>

[fabswt]

Anyone?

While the report is new, the bug has been around for at least 6 years and breaks basic SVG functionality.

[Ahmad Saleem]

Blink Commit: https://chromium.googlesource.com/chromium/src.git/+/d9569a659f3d68d7d96af8c751d5806402fca700

WPT Test Cases: https://wpt.fyi/results/svg/types/scripted?label=master&label=experimental&aligned=&q=svggraphicselement.getbbox-

[Karl Dubost]

Created attachment 476845 [details]
results of the console in Safari, Firefox, Chrome

With the proposed test case:

# SAFARI # 

<text xmlns="http://www.w3.org/2000/svg" x="60" y="125" font-size="92"><tspan>I</tspan><tspan>n</tspan><tspan>c</tspan><tspan>o</tspan><tspan>r</tspan><tspan>r</tspan><tspan>e</tspan><tspan>c</tspan><tspan>t</tspan></text>

<text>…</text>
SVGRect {x: 60, y: 42, width: 331.984375, height: 106}

<tspan>I</tspan>
  SVGRect {x: 60, y: 42, width: 331.984375, height: 106}

<tspan>n</tspan>
SVGRect {x: 60, y: 42, width: 331.984375, height: 106}

etc.

# FIREFOX #

<text>…</text>
SVGRect { x: 58, y: 56, width: 336.1666564941406, height: 92 }

<tspan>I</tspan>
SVGRect { x: 60, y: 56, width: 30.633333206176758, height: 92 }

<tspan>n</tspan>
SVGRect { x: 90.63333129882812, y: 56, width: 46, height: 92 }


# CHROME # 

<text>…</text>
SVGRect {x: 60, y: 42, width: 332.103515625, height: 106}

<tspan>​I​</tspan>​ 
SVGRect {x: 60, y: 42, width: 30.640625, height: 106}

<tspan>​n​</tspan>​ 
SVGRect {x: 90.640625, y: 42, width: 46, height: 106}


There is definitely a difference in between the 3 browsers here. 


The text case of WPT
https://wpt.fyi/results/svg/types/scripted/SVGGraphicsElement.getBBox-02.html?label=master&label=experimental&aligned


<svg height="100">
  <text y="180" font-size="100" font-family="Ahem" fill="lightblue" transform="translate(0, -100)">X<tspan fill="blue">X</tspan></text>
</svg>


Safari returns:
SVGRect {x: 0, y: 99.984375, width: 200, height: 100.015625}


Firefox returns
SVGRect { x: 100, y: 100, width: 100, height: 100 }

Chrome returns
SVGRect { x: 100, y: 100, width: 100, height: 100 }



There are probably two issues there. 
One which seems about rounding. and one which seems to be taking into account the transform.