Fix clipping on css-transformed elements

[eKoopmans]

Bug: Clipping on CSS-transformed elements

Elements with transform CSS apply a transformation directly to the canvas, adjusting all canvas actions. This causes incorrect clip bounds, since the transformations are not considered when calculating bounds.

Fix

Any canvas transform is temporarily undone while applying clips, then re-applied before rendering the element. This involved giving clip access to the container object to test for transforms.

Related issues/pull requests

#220, #349, #510, #978

[doubleppereira]

This would a good PR. Plus the webdriver task it's being skipped and at least is the first PR sucessful since long time ago.

[haxxxton]

@eKoopmans, just implemented this in my own fork, and found that it caused text to not render. The included examples basically rendered as if the the text had a transparent colour.

The if function is throwing an error when it tries to check .hasTransform on text node elements. The error message:

"Failed to execute 'getComputedStyle' on 'Window': parameter 1 is not of type 'Element'."

I fixed this by changing the NodeContainer.prototype.computedStyle function to be:

NodeContainer.prototype.computedStyle = function(type) {
    if (this.node.nodeType !== 3) {
    	return this.node.ownerDocument.defaultView.getComputedStyle(this.node, type);
    }
    return this.node.ownerDocument.defaultView.getComputedStyle(window.document.createElement('div'), type);
};

Unfortunately, this meant I needed to also update your .shadow function from PR #1086 to check if the shadow wasnt an empty string by changing the drawShadow function to:

var drawShadow = function(shadow) {
    if (shadow !== "") {
        var info = parseShadow(shadow);
        if (!info.inset) {
            context.shadowOffsetX = info.x;
            context.shadowOffsetY = info.y;
            context.shadowColor = info.color;
            context.shadowBlur = info.blur;
            context.fill();
        }
    }
};

[eKoopmans]

Hi @haxxxton, definitely interesting, I wasn't able to reproduce though: Fiddle (text shows up fine for me in this).

You'll notice here that for paintText I send container.parent to clip, so it looks like that parent is then having trouble. .hasTransform calls .parseTransformMatrix which calls .prefixedCss which calls .css, and when it gets there it needs to be an Element for getComputedStyle.

All that said, it should be sufficient to change line 72 of canvas.js to if (container instanceof Element && container.hasTransform()) {, but I'm curious what context it's getting a container that isn't an Element.

[haxxxton]

@eKoopmans, huge apologies about this.. as this isnt a pull request on a repo im in control of, i had to copy-paste the changes across, and i missed that subtle difference of container.parent over container. Changing it to the correct code fixes the comment i raised. Again, sorry for wasting your time :)

If you're interested in an npm accessible version of html2canvas that has a number of these PR's merged, you can have a look here.

[eKoopmans]

Hey @haxxxton, no worries, glad it was a simple fix. Thanks for the npm link!

[gharwood1]

Hey @eKoopmans

I believe this is causing a issue with:

.transform {
  -webkit-transform: rotate(-60deg);
  transform: rotate(-60deg);
}

Check out this fiddle

Thanks for your work!

[eKoopmans]

Hi @gharwood1, you're right that rotations still aren't handled correctly by this pull request (though it's still an improvement) - see issue #1138 for a bit more info, specifically this fiddle illustrates the problem. I've also created a modified version of your fiddle using divs, again to illustrate that clipping isn't being done correctly.

On Chrome at least, the fiddle you posted illustrates a second issue, which is that spans (and anything that's not display: block) shouldn't have any transforms applied to them (info here). So even though you've applied the rotate style, the original span appears un-rotated, but html2canvas rotates it. Definitely interesting!

Back to the original clipping issue: As I mentioned at #1138, fixing the clipping issue on rotated spans would require a much more serious rewrite of how clipping is being done in html2canvas. Right now html2canvas stores a stack of bounds information for all of an element's ancestors, and when drawing each element it applies the full stack of clips based on those bounds. Since the rotated element needs a rotated clip, either the bounds need to be stored in a rotated form and all further bounds need to have that rotation as part of their bounds calculation, or (better IMO) clipping and transforms can be applied as html2canvas descends through its children, so it can be applied correctly once and used for all children.

[eKoopmans]

Important update: This PR introduces new issues for certain CSS transformations and should be used with caution (see my last comment for more info). I apologize for any problems it may have caused.

@niklasvh, what are your thoughts on applying each node's clipping to the canvas as you descend down the tree, and restoring the canvas to its previous state on the way back out, rather than the current method of keeping an array of clipping bounds?

[niklasvh]

@eKoopmans I had a stab at overflows last night (as well as with transforms). They certainly are a bit problematic.

I think we cannot just apply the clips as we descend the tree as the drawing order of the canvas is based on stacking contexts instead of the DOM tree order (which overflows use). One alternative I thought about was applying transforms on a node level instead of globally for the whole stack and descendants, that way you could apply the clips along with the transforms together, in the right order. I've yet to try it out, and probably will first focus on getting the v1.0.0 branch up to par with the current functionality before I continue working on this.

[eKoopmans]

Right, fair enough. The other alternative could be to keep things as is but apply transforms to the clip vectors... Not sure if that would cause other problems.

[niklasvh]

That could be an alternative as well, but may get quite tricky with border-radius bezier curves etc?

[eKoopmans]

Yeah that was what stopped me when I started going down that path originally. I don't understand all the bezier calculations, especially with the inner and outer borders.

[niklasvh]

Will need to think about this a bit more, but for now focusing on getting the remaining features in first.

[eKoopmans]

This PR still needs work (see comment and #1138). The issue isn't yet resolved in v1.0.0-a1 when using non-foreignObject rendering.