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.
Created attachment 193566 [details] Reporter's testcase The previous testcase had an error in it, which prevented the bug from seeing it.
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...
I did try this with importNode but as you say that doesn't seem to be working yet.
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
OK. So there's something else up. Minimal testcase would be nice. :(
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...
(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).