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
•