Closed Bug 578309 Opened 14 years ago Closed 14 years ago

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


(Core :: SVG, defect)

Not set





(Reporter: Jeremie, Unassigned)



(1 file, 2 obsolete files)

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.

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
Attached image testcase
The green squares demonstrate the issue on using clipPath, the green circles demonstrate the issue on using mask.
Attached patch patch (obsolete) — Splinter Review
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
Ever confirmed: true
Attachment #457562 - Flags: review?(roc)
Blocks: 435356
Blocks: 578382
No longer blocks: 578382
Can we have a helper function to encapsulate GetAnimatedLengthValues plus Translate(...)*GetCanvasTM()?
Attached patch address review comment (obsolete) — Splinter Review
Attachment #457562 - Attachment is obsolete: true
Attachment #458792 - Flags: review?(roc)
Attachment #457562 - Flags: review?(roc)
Blocks: 498275
No longer blocks: 435356
Comment on attachment 458792 [details] [diff] [review]
address review comment

This is a regression in Firefox 3.6. Low risk patch, includes a test.
Attachment #458792 - Flags: approval2.0?
blocking2.0: --- → beta4+
Attachment #458792 - Flags: approval2.0?
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. 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.
Closed: 14 years ago
Resolution: --- → INVALID
No longer blocks: 498275
blocking2.0: beta4+ → ---
Keywords: regression
Assignee: longsonr → nobody
Attachment #458792 - Attachment is obsolete: true
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: 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 ( 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.