Using replaceChild on a listbox breaks the layout

RESOLVED INVALID

Status

()

Core
XBL
RESOLVED INVALID
12 years ago
11 years ago

People

(Reporter: //, Unassigned)

Tracking

({qawanted})

Trunk
x86
Windows 2000
qawanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 2 obsolete attachments)

1.27 KB, application/vnd.mozilla.xul+xml
Details
1.31 KB, application/vnd.mozilla.xul+xml
Details
(Reporter)

Description

12 years ago
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.
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.
Component: General → XBL
Product: Firefox → Core
Version: unspecified → Trunk

Updated

12 years ago
Assignee: nobody → general
QA Contact: general → ian

Comment 2

12 years ago
Created attachment 193557 [details]
Reporter's testcase
Created attachment 193566 [details]
Reporter's testcase

The previous testcase had an error in it, which prevented the bug from seeing
it.
Attachment #193557 - Attachment is obsolete: true

Updated

12 years ago
Summary: Using replaceChild on a listbox brakes the layout → Using replaceChild on a listbox breaks the layout
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...
Depends on: 251025
I did try this with importNode but as you say that doesn't seem to be working yet.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Can you retest with importNode now that that's fixed?
Created attachment 205231 [details]
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
Attachment #193566 - Attachment is obsolete: true
OK.  So there's something else up.  Minimal testcase would be nice.  :(
Keywords: qawanted

Comment 9

12 years ago
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.
Created attachment 206031 [details]
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.
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

11 years ago
(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.
OK, so this is invalid (certainly as a core XBL bug).
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.