Bug 14198 – (Re-)Enable <foreignObject> on feature-branch

• Status: RESOLVED
• Resolution: FIXED
• Component: SVG

[Nikolas Zimmermann]

<foreignObject> support should be on by default.

Though several things need to be tested/fixed:
- <use> on <foreignObject> needs to be disabled, as it could lead to nasty bugs
- <foreignObject> & plugins have to be tested (ie. Flash)
    any affine transformations are ignored when using <embed> for Flash atm.

[Nikolas Zimmermann]

Created attachment 15085 [details]
Initial patch

Complete patch reenabling <foreignObject. Plugins are not yet tested (needs discussion).

[Eric Seidel (no email)]

Comment on attachment 15085 [details]
Initial patch

I'm not sure why to remove it from SVG_EXPERIMENTAL_FEATURES?  That just makes it harder to merge with trunk...

I guess the point is, if we disallow <use> with <foreignObject> maybe we coudl push it to trunk soon anyway.  <foreignObject> isn't dangerous w/o <use>.  I'm not sure it's even dangerous with <use>, but it could be.

[Antoine Quint]

What exactly is the relationship between <foreignObject> and <use> in the WebCore code? I probably missed a fair amount of conversation around this, would be nice to learn more...

[Nikolas Zimmermann]

(In reply to comment #3)
> What exactly is the relationship between <foreignObject> and <use> in the
> WebCore code? I probably missed a fair amount of conversation around this,
> would be nice to learn more...

Hi Antoine,

the relationship between <use> & <foreignObject> is that it may cause
bad things. Internally we create a clone of the referenced element - if it's a
non SVG element we may end up inserting a HTML Render Tree object as
direct child in a SVG render object like RenderSVGContainer - which is really bad.
Leads to unexpected behaviour. Foreign objects like HTML elements, always have
to be inserted as RenderForeignObject children.
Another issue is the direct referencing of <use> & <foreignObject>. Our <use>
implementation uses a 'shadow tree' internally - a 1:1 cloned subtree of the
referenced element & it's children. HTML only uses shadow trees for our HTML Forms
Implementation internally - for SVG it has a totally diferent behaviour. So if we end up
creating our <use> shadow tree for _HTML_ elements - we are in trouble.

Easiest & safest way (to have a non-crashing Safari :-) is disabling these things.
Hope that clarifies it a bit...

Greetings,
Niko

[Nikolas Zimmermann]

Landed in r23618.

[Antoine Quint]

So is the problem <use> with a shadow tree containing a <foreignObject>? If so, couldn't we "just" disable <fO> in a shadow tree? I may misunderstand the complexity of such a restriction of course, but it seems to me that there is great value in having both <use> and <fO>, whereas I can see people living with the fact that <fO> can't be used within a shadow tree — for the moment.