Bug 239717

Ticket 237711 laid the groundwork for SVG transforms in LBSE, however there are still issues:

- SVG transforms specified alone on SVG elements, w/o any additional style/perspective related property such as transform-box / transform-origin / ...
  does not trigger layer creation (StyleAdjuster needs to consult SVG transforms as well, as special case, to determine if the animatedLocalTransform() is non-identity). This was missing.

- Switching on/off transforms for a SVG element, was not tracking updates to both 'HasSVGTransform' / 'HasTransformRelatedProperty' flags correctly, fix that.

And finally an important change with respect to LBSE downstream. In previous approach, the role of 'offsetFromAncestor' was changed for SVG, in e.g. paintLayerByApplyingTransform(). It did not measure the offsetFromAncestor in the same coordinate space as CSS. CSS layout does not consider transformations, everything is laid out as it's untransformed, and transforms are merely a painting effect. This is true for SVG on shape-level, but not for containers, since SVG containers are the union of the bounds of the children, mapped through the child transformations.

When SVGContainerLayout positions container children relative to itself, to "mimic" nested absolute positioned CSS boxes, it subtracts the container objectBoundingBox() location from the locations of the children. That is easy to implement, one doesn't need new geometry but can rely on objectBoundingBox(). However this makes SVG container 'internal boundaries' dependent on the transformations of the children. Therefore one needs to relayout the whole tree upwards, if the transformation changes in a non-accelerated way (SVGTransformList manipulation, SVG DOM, SMIL <animateTransform>, ...). Furthermore one needs to adapt RenderLayer to change the transformation style from "M * T" to "T * M", where T is the translation due to offsetFromAncestor() and M the user-defined transformation matrix.

This works fine, but there is a less-intrusive approach:
Compute a new geometry 'objectBoundingBoxWithoutTransformations' that is the same as objectBoundingBox(), but does not map contains children through their transformations. Change SVGContainerLayout to subtract that location instead of objectBoundingBox() location. This way the boundaries stay independent of the transformation. Hit-testing / painting via layers, still does respect the transformations, if present. This slightly changed approach, is way less confusing in the end, since the "M * T" logic (first translate to offsetFromAncestor, then apply transformation matrix, can stay as-is).

Patch for this approach will follow, that fixes most transform tests in LBSE, that are testable at present.