Could you share a URL or a file or a fiddle that illustrates the issue? (It's difficult to assess the issue without it.)

I have a function like so

var theta2 = 30;
var line1 = $(newG).find('#line1');
line1.attr('x2', 200);
line1.attr('x2', 200+l);
line1.attr("transform", "rotate(" + -theta2 + ", 200, 200)");

var svg = svgDoc.getElementById("svgdoc");
var p1 = getRelativeXY(200+l, 200, svg, line1[0]);

function getRelativeXY(x, y, svg, element){
	var p = svg.createSVGPoint();
	var ctm = element.getCTM();
	p.x = x;
	p.y = y;
	return p.matrixTransform(ctm);
}

I use this code to get the transformed coordinates of the tip of the line after rotation. Now it does not give the expected coordinates

I pass input a line and the svg element to find the coordinates 

Ok, could you provide a working (preferably minimal) example that demonstrates the issue? Without seeing the structure (of ancestors) that getCTM() needs to consider, it's difficult to check if there's something wrong.

Ok, I found the issue when making a simple minimal example. In earlier versions of Chrome, we could getCTM() on elements which are just created from code and not yet added to svg using addChild().
Now the getCTM() does not give correct values if the element created is not appended to the svg.

Thanks!

Ok, that's probably because of issue 369942 (not  issue 716711 .) Calling get{Screen,}CTM on an element that is not connected to the document is not guaranteed to give a correct result. We could restore the old fallback behavior, but it would still only mean that it works sometimes and gives the incorrect result sometimes. (IIRC Firefox behaves in a similarly unreliable way.)
Would you like us to restore the old fallback behavior?

Oh ok. But the issue which you refer to is from May 2014 (upto Dec 2016) but my code worked even earlier this year (even unto around March 2017) in Chrome versions before 57 (approximate version).

I would not recommend the "incorrect result sometimes" behavior but just would like to know the exact issue or change which caused this (maybe it might help you also for related issues by others in future)

https://bugs.chromium.org/p/chromium/issues/detail?id=369942#c25 would be the relevant change from that issue. That looks like it would have first been available in 57, which was released in early March.

Ok., Thanks for the update. I will use the new updated version of Chrome behavior. Thanks! 

The "issue" as such is that 'transform' is now a presentation attribute, and because of implementation details computed style is not available when an element is not connected to the document. (You would be able to observe this issue earlier as well if you had specified 'transform' as a CSS property on the element.)
Some things that has an effect on the transform of an element does not "suffer" from this limitation though - hence the "sometimes". This of course also means that a transform computed on an element not connected to the document could differ from the transform it will get when it _is_ connected to the document - even prior to the mentioned change. The same is also true for elements that _are_ connected to document but is not in the rendering tree (i.e has 'display: none' on itself or an ancestor.)
So relying on a transform computed on an element in any of these cases is perilous at best...

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

As I understand it this is WontFix because we cannot guarantee any sensible behavior.

Re-open if I'm wrong.