305603 - Using replaceChild on a listbox breaks the layout

Status: RESOLVED INVALID

(Core :: XBL, defect)

Description

[http://www.maple.nu]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

Using replaceChild on a listbox brakes the layout as this example shows:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>
<window class="dialog"
        xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
    <script type="application/x-javascript">
     <![CDATA[
     function reloadList()
     {
         var text ="<listbox
xmlns='http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul'
id='theList'> \
               <listitem label='These items do are not visible in the listbox'/> \
               <listitem label='And the listbox is 1px wide and high'/> \
             </listbox>"

         var parser=new DOMParser();
         var resultDoc = parser.parseFromString(text, "text/xml");
         document.getElementById("aBox").replaceChild(resultDoc.documentElement,
document.getElementById("theList"));
     }
     ]]>
     </script>
    <groupbox align="center" orient="horizontal" id="groupBox">
        <button label="Reload list" onclick="reloadList()"/>
        <vbox id="aBox">
            <listbox id="theList">
                <listitem label="Ruby"/>
                <listitem label="Emerald"/>
                <listitem label="Sapphire"/>
                <listitem label="Diamond"/>
            </listbox>
        </vbox>
    </groupbox>
</window>



Reproducible: Always

Steps to Reproduce:
1. Open XUL example in browser.
2. Press button

Actual Results:  
The listbox is updated but is only 1px wide and high.

Expected Results:  
We should be able to see the same listbox but with different listitems.

Comment 1

[Dave Townsend [:mossop]]

Looks like the xbl binding isn't getting applied to the listbox here. Not sure
whether this should work, xulplanet remarks that a number of things don't work
with this method.

Comment 2

[Mats Palmgren (inactive)]

Attachment: Reporter's testcase

Comment 3

[Martijn Wargers (dead)]

Attachment: Reporter's testcase

The previous testcase had an error in it, which prevented the bug from seeing
it.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Moving elements with bindings attached to them from one document to another
really doesn't work.  This code wants to be using importNode once we have that
working...

Comment 5

[Dave Townsend [:mossop]]

I did try this with importNode but as you say that doesn't seem to be working yet.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Can you retest with importNode now that that's fixed?

Comment 7

[Dave Townsend [:mossop]]

Attachment: Testcase using importNode

This is the same testcase but properly using importNode. This still appears broken to me.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051206 Firefox/1.6a1 ID:2005120616

Comment 8

[Boris Zbarsky [:bzbarsky]]

OK.  So there's something else up.  Minimal testcase would be nice.  :(

Comment 9

[Aiko]

The testcase uses DOMParser to generate XUL elements in a generic XML document and I noticed that the listbox has exactly the same broken look right from the start if you load it as text/xml. You can verify this yourself:

https://bugzilla.mozilla.org/attachment.cgi?id=205231&content_type=text/xml

So, isn't this is just a special case of what you said in bug 183641 comment 1? Some XUL elements must be "born" into a XUL document; they cannot be "healed" later by importing them into one.

Unfortunately DOMParser doesn't accept the XUL mime type so I couldn't test this theory further. Maybe somebody could try it with an iframe.

Comment 10

[Martijn Wargers (dead)]

Attachment: testcase3

Interesting difference when clicking on these 2 buttons.
They are nearly doing the same thing.
But with the second button, the text that is imported has one extra whitespace at the end of the string, just before </listbox>. That's the only difference.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Ah.  So thing is, parsing XUL as text/xml doesn't create the same DOM as parsing it with the XUL MIME type.  In particular, the latter strips out all sorts of whitespace...

I wouldn't be surprised if listbox somewhere assumes that all its kids are listitems, which would not be true in this case...

Comment 12

[[e-mail]]

(In reply to comment #11)
>I wouldn't be surprised if listbox somewhere assumes that all its kids are
>listitems, which would not be true in this case...
The listbox XBL only has insertion points for listcols, listhead and listitem.
Things go wrong if you add other children.

Comment 13

[Boris Zbarsky [:bzbarsky]]

OK, so this is invalid (certainly as a core XBL bug).