Appending children to BOX inside a TAB control does not display children

RESOLVED INVALID

Status

()

P3
major
RESOLVED INVALID
18 years ago
10 years ago

People

(Reporter: andreww, Assigned: eric)

Tracking

Trunk
PowerPC
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2-])

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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)
(Reporter)

Comment 1

18 years ago
Created attachment 10142 [details]
simple test case displaying problem.
(Reporter)

Comment 2

18 years ago
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.

(Reporter)

Comment 3

18 years ago
Nominating nsbeta2 due to bug which this depends on is nsbeta2+ in bugscape.
Keywords: nsbeta2

Comment 4

18 years ago
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.
Whiteboard: [nsbeta2-]
Target Milestone: --- → M20

Comment 5

18 years ago
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

Comment 6

18 years ago
Reporter, please verify. Thank you.

Updated

10 years ago
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.