Bug 23113 - Layer content inside HTML in SVG foreignObject renders in the wrong place
: Layer content inside HTML in SVG foreignObject renders in the wrong place
Status: NEW
: WebKit
SVG
: 528+ (Nightly build)
: Macintosh Mac OS X 10.5
: P2 Normal
Assigned To:
:
: InRadar
: 90738
:
  Show dependency treegraph
 
Reported: 2009-01-04 20:17 PST by
Modified: 2014-04-15 20:24 PST (History)


Attachments
Testcase (740 bytes, image/svg+xml)
2009-01-04 20:18 PST, Simon Fraser (smfr)
no flags Details
Work-in-progress patch (12.46 KB, patch)
2009-02-27 09:37 PST, Simon Fraser (smfr)
no flags Review Patch | Details | Formatted Diff | Diff
Another work-in-progress patch (14.13 KB, patch)
2012-02-03 13:55 PST, Florin Malita
no flags Review Patch | Details | Formatted Diff | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2009-01-04 20:17:43 PST
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.
------- Comment #1 From 2009-01-04 20:18:13 PST -------
Created an attachment (id=26421) [details]
Testcase
------- Comment #2 From 2009-02-25 23:07:38 PST -------
Hi,
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.
------- Comment #3 From 2009-02-25 23:24:13 PST -------
Yes, the problem is that the RenderSVGForeignObject does not have a RenderLayer, so that layers inside the HTML are not positioned correctly.
------- Comment #4 From 2009-02-26 00:41:57 PST -------
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.
------- Comment #5 From 2009-02-26 08:42:35 PST -------
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?
------- Comment #6 From 2009-02-26 10:26:59 PST -------
(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?
------- Comment #7 From 2009-02-26 10:30:07 PST -------
I have a hacked-up patch that I can attach when I get home. It has a number of issues, though.
------- Comment #8 From 2009-02-27 09:37:02 PST -------
Created an attachment (id=28077) [details]
Work-in-progress patch

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
------- Comment #9 From 2009-02-27 09:37:37 PST -------
Note that if you fix this bug, you'll probably fix bug 23111 too.
------- Comment #10 From 2010-07-08 02:19:28 PST -------
Changed component to SVG, so it shows up in my all-svg-bugs search.
------- Comment #11 From 2010-08-12 01:59:12 PST -------
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.


<?xml version="1.0"?>
<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"/>
  </mask>
  <defs>
    <g id="videoGroup">
      <foreignObject width="100%" height="100%">
        <body xmlns="http://www.w3.org/1999/xhtml">
          <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"/>
          </video>        
        </body>
      </foreignObject>
    </g>
  </defs>
  <use xlink:href="#videoGroup" mask="url(#c1)"/>
</svg>
------- Comment #12 From 2010-08-12 05:51:49 PST -------
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.
------- Comment #13 From 2010-08-12 06:07:07 PST -------
OK, done, see https://bugs.webkit.org/show_bug.cgi?id=43911
------- Comment #14 From 2011-07-28 15:44:07 PST -------
<rdar://problem/8912810>
------- Comment #15 From 2012-02-03 13:55:39 PST -------
Created an attachment (id=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.
------- Comment #16 From 2012-02-04 09:51:14 PST -------
(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.
------- Comment #17 From 2012-02-15 11:07:55 PST -------
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.
------- Comment #18 From 2012-02-15 14:47:48 PST -------
(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?
------- Comment #19 From 2012-02-16 07:52:31 PST -------
(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?
------- Comment #20 From 2012-11-05 11:22:47 PST -------
*** Bug 101237 has been marked as a duplicate of this bug. ***
------- Comment #21 From 2014-04-15 20:24:08 PST -------
*** Bug 131492 has been marked as a duplicate of this bug. ***