Closed
Bug 305603
Opened 19 years ago
Closed 18 years ago
Using replaceChild on a listbox breaks the layout
Categories
(Core :: XBL, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: maple.nu, Unassigned)
References
Details
(Keywords: qawanted)
Attachments
(2 files, 2 obsolete files)
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•19 years ago
|
||
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•19 years ago
|
Assignee: nobody → general
QA Contact: general → ian
Comment 2•19 years ago
|
||
Comment 3•19 years ago
|
||
The previous testcase had an error in it, which prevented the bug from seeing it.
Attachment #193557 -
Attachment is obsolete: true
Updated•19 years ago
|
Summary: Using replaceChild on a listbox brakes the layout → Using replaceChild on a listbox breaks the layout
![]() |
||
Comment 4•19 years ago
|
||
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
Comment 5•19 years ago
|
||
I did try this with importNode but as you say that doesn't seem to be working yet.
Status: UNCONFIRMED → NEW
Ever confirmed: true
![]() |
||
Comment 6•19 years ago
|
||
Can you retest with importNode now that that's fixed?
Comment 7•19 years ago
|
||
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
![]() |
||
Comment 8•19 years ago
|
||
OK. So there's something else up. Minimal testcase would be nice. :(
Keywords: qawanted
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•19 years ago
|
||
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•19 years ago
|
||
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•18 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.
![]() |
||
Comment 13•18 years ago
|
||
OK, so this is invalid (certainly as a core XBL bug).
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•