When HTML content inside an SVGForeignObject gets a RenderLayer for whatever reason, then it renders in the wrong place.
I guess this happens because the RenderLayer hierarchy does not extend through the SVG renderers, so the HTML RenderLayers have no knowledge of the SVG transforms etc.
Created attachment 26421 [details]
i have found out that in the html code if i remove the sytle attribute for div element the text inside the div element is renderred in the correct place and the bug is not seen> also if i change the opacity value of div to 1.0 the bug is not seen.
It looked strange. could anyone put more light on this.
Yes, the problem is that the RenderSVGForeignObject does not have a RenderLayer, so that layers inside the HTML are not positioned correctly.
Actually i dont think its the case in every html object, the bug is seen only when we apply opacity, if we remove opacity everrything works perfectly fine.And also other html elements are getting rendered properly.
could you please brief more on this.
Opacity makes a RenderLayer in the HTML. That RenderLayer is parented currently in the SVGRoot's layer, not the foreignObject's layer, so ends up in completely the wrong places.
Are you planning to work on this bug?
(In reply to comment #5)
> Opacity makes a RenderLayer in the HTML. That RenderLayer is parented currently
> in the SVGRoot's layer, not the foreignObject's layer, so ends up in completely
> the wrong places.
> Are you planning to work on this bug?
yes i am planing to work on this bug.which would be the better place or approach to resolve the issue?
I have a hacked-up patch that I can attach when I get home. It has a number of issues, though.
Created attachment 28077 [details]
Here's a work-in-progress patch. There are a number of things wrong with it:
* The RenderBox.cpp change needs cleaning up (see bug 23111 for some comments about that)
* The way that the layer paints with the ancestor transform seems weird
* Some SVG layout tests are broken
Note that if you fix this bug, you'll probably fix bug 23111 too.
Changed component to SVG, so it shows up in my all-svg-bugs search.
I have a similar problem, where I have a foreignObject in a <defs> and cannot apply a mask to it, because the foreignObject keeps getting rendered. I hope it can be fixed with the same fixes - if not, I can open a new bug.
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" height="270px" width="480px">
<mask id="c1" maskUnits="userSpaceOnUse" maskContentUnits="userSpaceOnUse">
<circle id="circle" cx="240" cy="135" r="135" fill="white"/>
<foreignObject width="100%" height="100%">
<video id="vid" class="target" height="270px" width="480px" controls="controls" autoplay="autoplay">
<source src="http://annodex.net/~silvia/itext/chocolate_rain/chocolate_rain.mp4" type="video/mp4"/>
<source src="http://annodex.net/~silvia/itext/chocolate_rain/chocolate_rain.ogv" type="video/ogg"/>
<use xlink:href="#videoGroup" mask="url(#c1)"/>
The foreignObject inside a defs sounds like a separate bug, please file. :)
CCing Ken, because his latest work needs to be aware of the possible interaction issues between layers and SVG.
OK, done, see https://bugs.webkit.org/show_bug.cgi?id=43911
Created attachment 125408 [details]
Another work-in-progress patch
I've updated Simon's patch and it works pretty well for the issue at hand (still a couple of rough edges to fix).
There's a major limitation with this approach though: the SVG paint context is lost with a separate layer - hence masks, filters, etc. on the FO's ancestor elements are not applied to embedded content.
I can't think of a way around this that doesn't involve some major RenderLayer surgery, so any ideas/comments are much appreciated.
(In reply to comment #15)
> I can't think of a way around this that doesn't involve some major RenderLayer surgery, so any ideas/comments are much appreciated.
I don't think there is an easy way. We'll probably have to glue RenderLayers together across foreignObject boundaries. We'd need one layer that knows all about the SVG transforms.
There is also a stacking problem: SVG specifies that elements are rendered in implicit order (elements should be "covering" their same-fragment predecessors). To preserve these semantics, we'll probably have to group FO sibling elements into additional synthetic layers to be composited in implicit order - pre-FO layer, FO layer, post-FO layer. Otherwise regular elements following a FO will be covered by it.
(In reply to comment #17)
> There is also a stacking problem: SVG specifies that elements are rendered in implicit order (elements should be "covering" their same-fragment predecessors). To preserve these semantics, we'll probably have to group FO sibling elements into additional synthetic layers to be composited in implicit order - pre-FO layer, FO layer, post-FO layer. Otherwise regular elements following a FO will be covered by it.
Exactly! I had fO + layers working until this point :-) This is the really problematic thing. Any SVG renderer would need to check if it follows a <fO/> - if yes, it has to return true for requiresLayer - probably requires some plumbing in RenderSVGBlock, RenderSVGInline, RenderSVGModelObject (+ another base class I probably forgot).
Once that works, we need testcases which moves <svg><g id="g1"/><fO/><g id="g2"/>.... eg. g1 behind g2, etc, to make sure we handle updates of the "pre-Fo layer, FO-layer, post-fO-layer" states properly. I could think of more tricky test cases as well...
Are you planning to work on that?
(In reply to comment #18)
> Exactly! I had fO + layers working until this point :-) This is the really problematic thing. Any SVG renderer would need to check if it follows a <fO/> - if yes, it has to return true for requiresLayer - probably requires some plumbing in RenderSVGBlock, RenderSVGInline, RenderSVGModelObject (+ another base class I probably forgot).
My initial thought was to group the elements following a FO into a hidden container and only create one additional layer. But that can be probably implemented later as an optimization (if needed at all) - your idea seems much more straightforward.
> Are you planning to work on that?
Sure, I've been chipping at this issue long enough now that I might as well keep doing it :) Do you have a saved patch that you can share?
*** Bug 101237 has been marked as a duplicate of this bug. ***
*** Bug 131492 has been marked as a duplicate of this bug. ***
*** Bug 165516 has been marked as a duplicate of this bug. ***
*** Bug 200383 has been marked as a duplicate of this bug. ***
*** Bug 32218 has been marked as a duplicate of this bug. ***
*** Bug 198660 has been marked as a duplicate of this bug. ***
Having the same issue with <foreignObject>. Any work on this issue?
Created attachment 391404 [details]
foreignObject and positioning bug
Attaching a test case.
It demonstrates the issue with `transform` breaking the positioning of foreignObject's children.
It also shows a workaround: `position: fixed` can be used to prevent the issue. Problem is it can't be used just anywhere.
In any case… This is a basic SVG functionality that's broken. Any chance to get a fix? It's been open for 11 years now.
I encountered this problem. When will it be resolved? There has been no progress for 11 years. Please speed up the solution of this problem.
I was about to file a bug regarding foreignObject content not being correctly scaled when using the zoom command +/- in Safari, but i think it is related to this bug.
As previous comments said, it occurs on elements with positioning, opacity, or transform.
Here is a test-case where the layout is fine, until you zoom in or out the page: https://codepen.io/chototoro/pen/gOpqjEX
Created attachment 404542 [details]
Showing defect using scrolling section
This shows the defect using a div which contains a scrollable section.
The inner-document has these CSS settings:
The moment the size exceeds the space to the foreignObject the render error happens.
any updates? no wonder people call safari the new ie)
Same issue in Safari v14.0
is there any chance to get this fixed?
This issue was also on chromium but has now been fixed in chrome 87 - which was stable as November 17th, 2020
The chromium bug is here:
which is a duplicate of this related bug:
The test case used for this bug was:
This test currently passes on the chrome 87 but fails on safari 14.
Would be great if this could fixed to have standardized SVGForeignObject behavior.
seems like the best way to reproduce issue. this test was comment in:
I encountered this bug as part of my workflow and found that the issue that was causing it was due to position: relative/absolute elements in the foreignObject.
I made a demo to show the differences in behavior (try in chrome vs safari)
This is a pretty big blocker which prevents usage of foreignObject in Safari for our project. Hopefully the demo provided will help the bugfix.