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
Created attachment 457034 [details] testcase The green squares demonstrate the issue on using clipPath, the green circles demonstrate the issue on using mask.
Created attachment 457562 [details] [diff] [review] 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.
Assignee: nobody → longsonr
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #457562 - Flags: review?(roc)
Can we have a helper function to encapsulate GetAnimatedLengthValues plus Translate(...)*GetCanvasTM()?
Created attachment 458792 [details] [diff] [review] address review comment
Attachment #458792 - Flags: review?(roc) → review+
Comment on attachment 458792 [details] [diff] [review] address review comment This is a regression in Firefox 3.6. Low risk patch, includes a test.
Landed and backed out due to mochitest failures. Not sure whether the error is in the tests or code yet.
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INVALID
No longer blocks: 498275
blocking2.0: beta4+ → ---
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 :)
You need to log in before you can comment on or make changes to this bug.