1423973 - Value of getComputedTextLength() on <text> with textLength can be different

Status: RESOLVED INVALID

(Core :: SVG, defect, P1)

Description

[Philipp Pief]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20171204150510

Steps to reproduce:

Let's say I have interactive JS-powered SVG content with <text> elements in it I just want to squish but never stretch its text into a box of a certain width (see https://github.com/w3c/svgwg/issues/341 ) then I would have to use getComputedTextLength() to determine the length to decide whether to set "textLength" or not. In my case I am also using 'lengthAdjust="spacingAndGlyphs"'.


Actual results:

If I use getComputedTextLength() on a <text> which already has "textLength" set on it (so in my case the squishing already happened) then under certain circumstances it will not return values smaller than the "textLength" value (e.g. "textLength" is 145 and getComputedTextLength() might give me 144.99998474121094). The decision logic in my case then caused the "textLength" value to be unset which would mean that it would be set again in the next update function call thus causing the text to switch back and forth between being squished and not.

I didn't manage to reliably reproduce it and create a minimal test case as it seems to be depended on many factors, e.g. I could only reproduce it on Windows and never on Linux. Also there need to be one or more transforms involved (transform="translate(X,Y) scale(K)") with certain values.


Expected results:

In Google Chrome and Microsoft Edge I didn't ever come across this issue, possibly getComputedTextLength() is short-cutted there if "textLength" is used. While one could argue that this behavior might not be correct in principle it might be what web developers come to expect (also, improved performance?). 

BTW, I can reproduce the issue in Internet Explorer 11 though, it even seems to be more likely to happen there. Didn't test Safari.

Comment 1

[Robert Longson [:longsonr]]

Without a testcase we're not really going to be able to do anything here.

Comment 2

[Philipp Pief]

Well, even without testcase you could think about implementing the aforementioned shortcut.

Still I will see whether I can at least produce a static website which shows the issue on this one system here but like I was only able to reproduce it on Windows and I suspect the DPI value might also play a role.

Comment 3

[Philipp Pief]

Attachment: Partial testcase

OK, I came up with a testcase after all, but only one which shows a getComputedTextLength value a bit larger than the "textLength" value (in my case 145.00001525878906).

Thanks to this testcase I also noticed that Chrome does not short-cut the call but instead its getComputedTextLength() apparently returns a value before "textLength" was applied. In Edge my shortcut hypothesis seems to apply though.

Comment 4

[Philipp Pief]

Attachment: Another static testcase

Now I even came up with a testcase which returns a value smaller than the textLength (145), in my case 144.99998474121094.

Comment 5

[Philipp Pief]

Note that even on Linux I can get different getComputedTextLength() results in the test cases, even those below 145 at various page zoom levels, so apparently page zoom also plays a role and it's not an OS specific issue. Odd that in my application the problem would never show up on Linux.

Comment 6

[Philipp Pief]

See also https://bl.ocks.org/Herst/raw/a304caf946e59a7e34c24bd828fa0b3a/?textLength=200 for another testcase of how the computed value can differ from the textLength value even if no transforms are involved.

Comment 7

[Philipp Pief]

Forget what I said about Edge, it does not shortcut either.

Comment 8

[Philipp Pief]

A similar discussion over at the Chromium bug tracker basically showed me that getComputedTextLength() simply is broken in many ways and that this would be first and foremost a standards issue: https://bugs.chromium.org/p/chromium/issues/detail?id=793965#c5