Bug 14198 - (Re-)Enable <foreignObject> on feature-branch
Summary: (Re-)Enable <foreignObject> on feature-branch
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 523.x (Safari 3)
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Nikolas Zimmermann
Depends on:
Reported: 2007-06-17 09:41 PDT by Nikolas Zimmermann
Modified: 2007-06-19 23:54 PDT (History)
2 users (show)

See Also:

Initial patch (26.15 KB, patch)
2007-06-17 09:44 PDT, Nikolas Zimmermann
eric: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nikolas Zimmermann 2007-06-17 09:41:18 PDT
<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.
Comment 1 Nikolas Zimmermann 2007-06-17 09:44:37 PDT
Created attachment 15085 [details]
Initial patch

Complete patch reenabling <foreignObject. Plugins are not yet tested (needs discussion).
Comment 2 Eric Seidel (no email) 2007-06-18 10:03:52 PDT
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.
Comment 3 Antoine Quint 2007-06-18 10:08:58 PDT
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...
Comment 4 Nikolas Zimmermann 2007-06-19 15:39:06 PDT
(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...

Comment 5 Nikolas Zimmermann 2007-06-19 15:42:37 PDT
Landed in r23618.
Comment 6 Antoine Quint 2007-06-19 23:54:34 PDT
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.