578309 - mask and clipPath applied to foreignObject does not honor the global coordinates system

Status: RESOLVED INVALID

(Core :: SVG, defect)

Description

[Jeremie Patonnier :Jeremie]

User-Agent:       Mozilla/5.0 (Windows; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100712 Minefield/4.0b2pre
Build Identifier: Mozilla/5.0 (Windows; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100712 Minefield/4.0b2pre

When you apply a mask or a clipPath to a foreignObject without transformation, the clipPath is well applied but it is located exactly like the foreignObject determine a new coordinate system where the upper left corner of this foreignObject act like a 0,0 coordinate point.

As far as I know there is nothing in the SVG spec that validate such a behavior.
(see http://www.w3.org/TR/SVG11/extend.html)

Reproducible: Always

Steps to Reproduce:
1. See the attach testcase
Actual Results:  
You can see a red croissant inside one of the green squares and a green circle is missing.

Expected Results:  
You should see 2 green squares and 2 green circles

Comment 1

[Jeremie Patonnier :Jeremie]

Attachment: testcase

The green squares demonstrate the issue on using clipPath, the green circles demonstrate the issue on using mask.

Comment 2

[Robert Longson [:longsonr]]

Attachment: patch

Great testcase again Jeremie.

We need to apply the transform when we are processing the foreignObjectFrame but other frames such as the clipPath which call foreignObjectElement()->getCanvasTM should not be translated.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Can we have a helper function to encapsulate GetAnimatedLengthValues plus Translate(...)*GetCanvasTM()?

Comment 4

[Robert Longson [:longsonr]]

Attachment: address review comment

Comment 5

[Robert Longson [:longsonr]]

Comment on attachment 458792 [details] [diff] [review]
address review comment

This is a regression in Firefox 3.6. Low risk patch, includes a test.

Comment 6

[Robert Longson [:longsonr]]

Landed and backed out due to mochitest failures. Not sure whether the error is in the tests or code yet.

Comment 7

[Robert Longson [:longsonr]]

Rather embarassingly, and as the mochitest failures showed, this whole bug is invalid.

http://www.w3.org/TR/SVG/masking.html#clipPath-geometry says...

If attribute ‘clipPathUnits’  is not specified, then the effect is as if a value of 'userSpaceOnUse' were specified.

If clipPathUnits="userSpaceOnUse", the contents of the ‘clipPath’ represent values in the current user coordinate system in place at the time when the ‘clipPath’  element is referenced (i.e., the user coordinate system for the element referencing the ‘clipPath’ element via the ‘clip-path’ property).

Other implementations of foreignObject clipping are buggy which confused me but replacing foreignObject by an svg tag and clipping that shows consistent results across Opera, the Adobe plug in and Firefox.

So this isn't a regression in Firefox 3.6, it was actually something that was fixed for Firefox 3.6.

Comment 8

[Jeremie Patonnier :Jeremie]

Ok, I see the point.

But what is important is not the way clipPathUnits act. The important thing I did not see previously was that foreignObject redefine a new viewPort (see: http://www.w3.org/TR/SVG/coords.html#EstablishingANewViewport) and that's why clipPath adjust itself to a new coordinate system.

The SVG spec is somewhat confusing because this behavior is not mention in the extensibility part of it (http://www.w3.org/TR/SVG/extend.html). I had to perform a lot of cross searching in the spec to understand your point. I think that a lot of end users will be confused as well as I was here. And as you said, if almost all other browser handle it wrong I guess it's maybe for such a misunderstanding.

Thanks any way :)