SVG object covers CSS background in HTML foreignObject The example shows an SVG inside a HTML page. The SVG in turn contains a group with a red 'rect' and a 'foreignObject'. The latter contains a HTML 'div' with a CSS class that defines bold font and yellow background. Everything is layered in a way that the foreignObject covers most of the red 'rect'. Expected behaviour: The HTML div is entirely visible and has a yellow background. Works in FF4. Actual behaviour: (Chrome 11 Beta, WebKit 534.24 (branches/chromium/696@83359)): The red 'rect' covers the yellow background of the HTML div. ---8<--- <html> <head> <title>SVG object covers CSS background in HTML foreignObject</title> <style> .My_Class { font-weight: bold; background: yellow; } </style> </head> <body> <div class="My_Class">Raimi was here</div> <svg id="svgWorld" xmlns="http://www.w3.org/2000/svg" width="500px" height="500px"> <g transform="translate(20, 20)"> <rect x="0" y="0" width="50" height="10" fill="red" /> <foreignObject x="5" y="1" width="200" height="20"><div class="My_Class">Raimi was here, too</div></foreignObject> </g> </svg> </body> </html>
Created attachment 89349 [details] What FF4 does, correct.
Created attachment 89350 [details] What Chrome 11 Beta does, incorrect.
Created attachment 89351 [details] Testcase again as separate file
Created attachment 89353 [details] Same thing in plain SVG file Demonstrates same issue, does not use CSS class but HTML style Attribute.
PS: I believe this also interferes with (mouse) event handlers that are bound to the HTML-Div inside the foreignObject. They sometimes do not fire while over a "background-only" area. I'm not 100% sure - anyone interested in an extended testcase?
Created attachment 113057 [details] Patch
Comment on attachment 113057 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=113057&action=review Looks good to me on first sight, but r- as it duplicates code. I wonder about the possible implications/side-effects though. I'd prefer if Dave/Simon/Dan could have a look! I'd want to hear their comments too. > Source/WebCore/rendering/svg/RenderSVGForeignObject.cpp:66 > + // Paint all phases of FO elements atomically, as though the FO element established its > + // own stacking context. Can't you share this code between InlineBox and RenderSVGFO in a common base? Replicating this is not a good idea.
Comment on attachment 113057 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=113057&action=review >> Source/WebCore/rendering/svg/RenderSVGForeignObject.cpp:66 > > Can't you share this code between InlineBox and RenderSVGFO in a common base? > Replicating this is not a good idea. Sounds like a good idea, but there's a couple of things that make this tricky: * InlineBox & RenderSVGFO don't share a common base (InlineBox is a top level class) * while InlineBox::paint() just calls paint() on its RenderObject reference, RenderSVGFO::paint() delegates to a specific super method (RenderBlock::paint()) I'm not familiar enough with the code base to see a clean way around these - any suggestions?
Created attachment 114116 [details] Patch
Dave/Simon: do you mind taking a look at this? (not sure which Dan is Nikolas referring to, but hopefully I got the two of you right)
Comment on attachment 114116 [details] Patch I think this a good change, but longer term maybe SVGFO needs it own RenderLayer which would do this.
(In reply to comment #11) > (From update of attachment 114116 [details]) > I think this a good change, but longer term maybe SVGFO needs it own RenderLayer which would do this. Great, thanks for looking quickly Simon. I've discussed this with Dirk some days ago. I still have an older patch lying around that adds a RenderLayer to RenderSVGFO/Root, but it's not complete at all.
(In reply to comment #12) > (In reply to comment #11) > > (From update of attachment 114116 [details] [details]) > > I think this a good change, but longer term maybe SVGFO needs it own RenderLayer which would do this. > Great, thanks for looking quickly Simon. I've discussed this with Dirk some days ago. > I still have an older patch lying around that adds a RenderLayer to RenderSVGFO/Root, but it's not complete at all. ...and I plan to continue working on it soon :)
Is the plan still to commit this as a temporary fix then? I have another patch which depends on atomic FO painting to pass its tests, so I think that would make sense.
(In reply to comment #14) > Is the plan still to commit this as a temporary fix then? I have another patch which depends on atomic FO painting to pass its tests, so I think that would make sense. Yes, go ahead.
Comment on attachment 114116 [details] Patch Rejecting attachment 114116 [details] from commit-queue. schenney@chromium.org does not have committer permissions according to http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/config/committers.py. - If you do not have committer rights please read http://webkit.org/coding/contributing.html for instructions on how to use bugzilla flags. - If you have committer rights please correct the error in Tools/Scripts/webkitpy/common/config/committers.py by adding yourself to the file (no review needed). The commit-queue restarts itself every 2 hours. After restart the commit-queue will correctly respect your committer rights.
Comment on attachment 114116 [details] Patch Clearing flags on attachment: 114116 Committed r99862: <http://trac.webkit.org/changeset/99862>
All reviewed patches have been landed. Closing bug.