317758 - SVG doesn't render correctly when interleaved as shadow content using XBL

Status: RESOLVED INVALID

(Core :: SVG, defect)

Description

[Robin Berjon]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/412.6 (KHTML, like Gecko) Safari/412.2
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

If you have a simple tree <parent><child/></parent> which has XBL bindings for both elements, where <parent> is bound to have an <svg> element as its shadow tree, where said <svg> element includes all XBL children, and where <child> is bound to have an SVG <rect/> as its shadow tree, the latter <rect/> should render as if it were a directly child of the <svg> element.

Currently that isn't the case, nothing included through xbl:children in an SVG shadow tree will ever render (presumably because the renderer sees a non-SVG element and decides to ignore it, while it should check its shadow tree for SVG content before doing that).

This makes using SVG and XBL together pretty much impossible in any significant way, which is obviously quite a shame.

Reproducible: Always

Steps to Reproduce:
1. See attached document

Actual Results:  
Doesn't display SVG shadow tree.

Expected Results:  
Should display SVG shadow tree.

Comment 1

[Robin Berjon]

Attachment: Short example displaying the problem

Comment 2

[Boris Zbarsky [:bzbarsky]]

> the latter <rect/> should render as if it were a directly child of the <svg>
> element.

Why?  That's certainly not the case in Mozilla XBL -- in Mozilla XBL the <parent> and <child> both generate layout objects.  In this particular case, they are CSS inlines.  The flattened tree in this case is:

<parent>
  <svg:svg>
    <svg:rect />
    <child>
      <svg:rect />
    </child>
  </svg:svg>
</parent>

And renders as you would expect that to render.  Further, I just checked and this is the behavior that sXBL also specifies, as do the various "XBL2" versions out there, so I see no reason to change it, and many reasons NOT to change it (foremost being that it would break most existing XBL consumers).

Note that this sort of situation is exactly why Mozilla XBL has xbl:extends.