by "all works well" in the last sentence I meant one can obtain proper coordinates for the element after transformation.

Drag rotate & scale function extract:

this.move = function(event) {
        event.preventDefault();
		eventObj = isTouchSupported? event.touches[0] : event;
        var p = widget.services.globalToLocalCoordinates(eventObj.clientX, eventObj.clientY);
        var rdx = morphTarget.rotation.center.x - p.x;
        var rdy = morphTarget.rotation.center.y - p.y;
        var theta = 90 + Math.atan2(rdy, rdx) * 180 / Math.PI;
        var sdx = morphTarget.scale.point.x - p.x;
        var sdy = morphTarget.scale.point.y - p.y;
        var d = Math.sqrt(sdx * sdx + sdy * sdy);
// THIS IS WHAT USED TO WORK IN 56:
        //var transform = "rotate(" + theta + " " + morphTarget.rotation.center.x + "," + morphTarget.rotation.center.y + ") translate(" + morphTarget.rotation.center.x + "," + morphTarget.rotation.center.y + ") scale(" + d / morphTarget.scale.height + ") translate(" + (-morphTarget.rotation.center.x) + "," + (-morphTarget.rotation.center.y) + ")";
// THIS IS WHAT "WORKS" IN 57 UNTIL ONE TRIES TO CONSOLIDATE MATRIX:
        var transform = "rotate(" + theta +") scale(" + d / morphTarget.scale.height + ")";
        morphTarget.setAttribute("transform", transform);
        //this.target.setAttribute( "transform", transform);
    }.bind(this);

This is what I meant by "obtaining absolute coordinates":

this.target.flattenPath = function() {
            console.log("flattening transform for a shape");
            var matrix = this.transform.baseVal.consolidate().matrix;
            //console.log(matrix, this);
            for (i = 0; i < this.pathPoints.length; i++) {
                var position = this.ownerSVGElement.createSVGPoint();
                position.x = this.pathPoints["p" + i].x;
                position.y = this.pathPoints["p" + i].y;
                position = position.matrixTransform(matrix);
                this.pathPoints["p" + i].x = (position.x).toFixed(2);
                this.pathPoints["p" + i].y = (position.y).toFixed(2);
            };
            console.log(this.pathPoints)
            this.setAttribute("d", this.constructPath());
            this.setAttribute("transform", "matrix(1 0 0 1 0 0)");
    };

Could you please help providing a html or jsfiddle to investigate it further from TE side. Also could you please check if its related to  issue 701075 .

Hi, I recreated the case and I can not reproduce the bug yet.
http://codepen.io/cmer41k/pen/XpKWBq

I will spend some more time researching. It may reproduce only in combination of other things that I have on my web-site.

Checking.

Thank you for providing more feedback. Adding requester "durga.behera@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

OK I found the issue and ...it might not be a bug but unexpected behavior.

My original CSS had "transform-origin" for the shape CSS animation set to "center".
In the past CSS transform properties didn't affect SVG. Now it seems CSS can do that.
See the snippet in the codepen. Steps to reproduce:

1. Drag rotate the square shape.
2. In console execute shape.flattenPath();
3. See how matrix changes to (1 0 0 1 0 0) and the shape moves into other location.

Feels like CSS should be used to control SVG in SVG 2 in future and maybe those changes are already being rolled-in. Hence the behavior.

I think this is a related post here:
http://stackoverflow.com/questions/35584286/svg-transform-origin-not-working-in-chrome

Yes, since 57 'transform' has been turned into a presentation attribute (see issue 369942.) This means that the 'transform' attribute value takes part in the CSS cascade, and 'transform-origin' applies both when specifying 'transform' as an attribute and as a CSS property. If you want to bring the old behavior back, it should suffice to remove the 'transform-origin' property, or set it to '0 0' instead (which is what it is set to by the UA stylesheet.)

Working as intended then? Marking WontFix. Reopen if that's not correct.

That SO issue is indeed the "reverse" issue ('transform-origin' not applying), and Chrome should now match Firefox/Gecko in that case.

wont fix is a proper state - agreed.