If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

svg getBBox() on text elements returns wrong rectangle data

VERIFIED FIXED

Status

()

Core
SVG
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: thomas.smailus, Unassigned)

Tracking

31 Branch
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

3 years ago
Created attachment 8500671 [details]
getBBox test.svg

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0
Build ID: 20140825060242

Steps to reproduce:

Load attached SVG diagram, which calls getBBox() on a text element in the diagram and reports back the result.  The result does not make sense for the text element's precisely known location and dimension specification.


Actual results:

A text string is positioned at 110,110 textLength=30 font-size=10
calling getBBox() returns 
(x,y)=(0,-14.839999198913574); 
w:131.4351806640625; 
h:129.29200744628906
with some variation in the decimal places depending on the Firefox window size.


Expected results:

Should have retuned x,y = 110,110 and width=30  and height around 10 (driven by font-size)
Component: Untriaged → SVG
Product: Firefox → Core

Comment 1

3 years ago
Height is affected by ascenders and descenders. y is affected by leading.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INVALID
(Reporter)

Comment 2

3 years ago
Yes, that is true, so I'd expect height to be somewhere around 10 but not 129.2xx.
If the position is 110,110, the location for y should be around 110, not -14.83

And x should be around 110, not 0
(Reporter)

Comment 3

3 years ago
Marked as invalid - I don't see how - please explain... setting status to Unconfirmed.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---

Comment 4

3 years ago
x is around 110 and y is around 97 on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0

I'll check Windows.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago3 years ago
Resolution: --- → INVALID

Comment 5

3 years ago
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0

basically the same i.e. 110,95.4

Could be something fixed in 32 or maybe something add on is breaking things for you
Status: RESOLVED → VERIFIED
(Reporter)

Comment 6

3 years ago
This isn't fixed on 31.1.0 ESR - thats where it needs to be fixed.  Is the ESR release an 'other' branch or how does one indicate this?

Comment 7

3 years ago
Are you saying that 32 works but 31 esr does not? If so and you find what fixed it via http://mozilla.github.io/mozregression/ then it might be possible for that fix to be ported to ESR 31 depending on how big the patch is and what it depends on.
(Reporter)

Comment 8

3 years ago
I know the bug exists in Firefox ESR 31.1.0  (and it used to not exist in the ESR 24.x version we were using before - so our ESR regressed in functionality by going to ESR 31.1.0.

You indicated that it is fixed in main line 32.0.

Testing myself in Firefox 33.0 it seems to be fixed, or at least better.
The sample test case text that starts at 110,110 and has textLength=30, font=10 returns a bbox of x,y=108.75, 97.20 width=33.75, h=15.36

So the bounding box, while the bounding box is still more expansive than I'd expect given the text is specified as starting at 110,110 and (so why the BBox comes back starting at < 110 is a point of discussion, or why the height is 15.36 if the font size is 10 )  at least the bounding box is in a usable area (bbox.x is no longer negative and off the screen)

This issue is related to how BBox is compute when the text has some whitespace in it, specifically leading newline and tab characters.  The problem manifests because the SVG test case has text defined as follows:

	<text id="inText" x="110" y="110" textLength="30" lengthAdjust="spacingAndGlyphs" text-anchor="start">
		<tspan  font-family="ocrb ata" fill="black" id="SS61" font-size="10"  >TERM-S</tspan>
	</text>

So the text starts with a newline and then two tabs and the the tspan, followed by another newline and tab.  I believe the computation of the bounding box when the text starts and ends in whitespace is the underlying issue.

I've attached an enhanced test diagram, that takes that initial test and adds a a rectangle (green) that is resized to the position and dimensions reported by getBBox().  The grey rectangle depicts the zone specified to cover the area from the text location with a width of the textLength, and a height of the font-size.  The orange/peach box depicts the region that is the SVG viewBox, for orientation purposes.
(Reporter)

Comment 9

3 years ago
Created attachment 8511329 [details]
Test getBBox on a text-tspan combination with leading and trailing whitespace

Comment 10

3 years ago
The bounding box allows for ascenders i.e. the decender of a y and an accent on a capital so it's bigger than the actual text you use in the case you have.

What's left sounds like bug 1019555 then. I'm not sure we'd port that to ESR but you could try asking in that bug.
Resolution: INVALID → FIXED

Updated

3 years ago
Depends on: 1019555
You need to log in before you can comment on or make changes to this bug.