| Summary: | (Re-)Enable <foreignObject> on feature-branch | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Nikolas Zimmermann <zimmermann> | ||||
| Component: | SVG | Assignee: | Nikolas Zimmermann <zimmermann> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | ml, zimmermann | ||||
| Priority: | P2 | ||||||
| Version: | 523.x (Safari 3) | ||||||
| Hardware: | Mac | ||||||
| OS: | OS X 10.4 | ||||||
| Attachments: |
|
||||||
Created attachment 15085 [details]
Initial patch
Complete patch reenabling <foreignObject. Plugins are not yet tested (needs discussion).
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.
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... (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 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. |
<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.