Setup: Create a tab control in which in one panel you place a box (empty). Set it's style to be "overflow"auto;". Append a new xul element to it via "appendChild()" Expected results: the appended children appear. Actual results: the XUL shifts to accomodate the space the new child would take up but it does not display. Note: if you remove the style--overflow:auto; the children _DO_ appear. This is needed for scrolling elements in the Edit Addressbook Tab - the AIM overlay must display all the groups one could add that entry to , but if the groups are too many, the window get's too large for the view and you cannot resize it on Mac. I'm attaching a Simple Test Case (tm)
Explaination of the test case: load up the page in mozilla click on the "add to tab 1" button. You will see children being added to the box. Now click the 3rd tab. Click the "add to tab 3 button. Keep clicking about 10 or so times. None of the children will display, but they will "take up space". The difference between the two tabs is that the 3rd one has : style="overflow:auto;" plus some height/width.
Nominating nsbeta2 due to bug which this depends on is nsbeta2+ in bugscape.
marking nsbeta2-. It is unusual for users to have a large number of groups in their buddy list. Furthermore, most users are not using the address book to edit their buddy lists.
Doh! Andrew, you have a typo in your testcase -- both forms of the onclick handler are appending their content to the <box> in the first tabpanel. If you point the addDom2() version at the <box> in the third tabpanel, then everything works A-OK. marking invalid (not a bug), but thanks for the testcase [when amended for the error]. Reopen if it's just late and I am cluelessly missing your point.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → INVALID
Reporter, please verify. Thank you.
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.