Steps to reproduce: 1. Enable XBL form controls (Preferences -> Debug) 2. Go to http://bugzilla.mozilla.org/query.cgi and do a query that will give a list of bugs. 3. Click the "Change several bugs at once" link at the bottom of the page. Result: The table has become several thousand pixels wide, leaving a large empty area between the ID and Severity columns. This is a blocker for turning on XBL checkboxes.

bryner: could you attach a less complicated testcase? ;-), where is the maxelementsize for the XBL checkboxes computed?

Using XBL- based form controls are still in construction. That might be reason for this error. I cant find the link "Change several bugs at once" at the bottom of the query list page.

Marking nsbeta1+

This is a fairly reduced testcase for the problem. For the problem to appear, it seems to be necessary to have two rows in the table, both of which contain a checkbox.

I'm not seeing the problem with a 2/11/2 build; the checkboxes looked fine. Have xbl form controls changed that much in a day or am I doing something wrong.

a correct initial reflow without xbl form controls area 00E49298 r=1 a=9180,UC c=9180,UC cnt=899 block 00E49580 r=1 a=9180,UC c=8940,UC cnt=900 text 00E4980C r=0 a=8940,UC c=UC,UC cnt=901 text 00E4980C d=0,0 tblO 00E499DC r=0 a=8940,UC c=0,0 cnt=902 tbl 00E5A37C r=0 a=8940,UC c=UC,UC cnt=903 rowG 00E5A51C r=0 a=UC,UC c=UC,UC cnt=904 row 00E5A680 r=0 a=UC,UC c=UC,UC cnt=905 cell 00E5A7F4 r=0 a=UC,UC c=UC,UC cnt=906 block 00E5A854 r=0 a=UC,UC c=UC,UC cnt=907 CheckboxControl(input)(0) 00E5AB3C r=0 a=UC,UC c=135,135 cnt=908 CheckboxControl(input)(0) 00E5AB3C d=195,195 me=195 text 00E5AC88 r=0 a=UC,UC c=UC,UC cnt=909 text 00E5AC88 d=600,285 me=600 block 00E5A854 d=900,285 me=600 cell 00E5A7F4 d=930,315 me=630 the bad reflow with xbl area 02ED4154 r=1 a=15225,UC c=15225,UC cnt=653 block 02ED443C r=1 a=15225,UC c=14985,UC cnt=654 text 02ED46A8 r=0 a=14985,UC c=UC,UC cnt=655 text 02ED46A8 d=0,0 tblO 02ED4878 r=0 a=14985,UC c=0,0 cnt=656 tbl 02ED4A48 r=0 a=14985,UC c=UC,UC cnt=657 rowG 02ECC2B4 r=0 a=UC,UC c=UC,UC cnt=658 row 02ED4D1C r=0 a=UC,UC c=UC,UC cnt=659 cell 02ED4E90 r=0 a=UC,UC c=UC,UC cnt=660 block 02ED4EF0 r=0 a=UC,UC c=UC,UC cnt=661 inline 02ED521C r=0 a=UC,UC c=UC,UC cnt=662 inline 02ED521C d=60,300 me=0 text 02ED5288 r=0 a=UC,UC c=UC,UC cnt=663 text 02ED5288 d=600,285 me=600 block 02ED4EF0 d=765,285 me=600 cell 02ED4E90 d=795,315 me=630 problems: 1. the inline as a replacement for the checkbox is to small 60twips instead of 195 2. the reported maxElementsize is 0 -> tables could squeeze it down to zero. This is not a table problem. If the xbl form element will report correct sizes as the non-xbl counterpart the reflow will work as expected. I have no idea how one should debug the xbl elements, till yesterday they even did not work in viewer.

Thanks Bernd, --> XBL, CCing attinasi.

Actually, this is a XUL box bug.

taking, i have a fix

Ok, here's what the problem was. nsLeafBoxFrame::Reflow was not setting maxElementSize during the reflow. In a debug build, we check this against a bogus 0xdeadbeef starting value and clear it to 0 if it's not set, so this problem only shows up in non-debug builds. Anyway, nsLeafBoxFrame::Reflow should work exactly like nsBoxFrame::Reflow, except that they can't share the implementation due to the LeafFrame/ContainerFrame class structure. What I did was synced up nsLeafBoxFrame's version with the current nsBoxFrame version, which does the right thing. I added the slight optimization of not checking NS_STATE_IS_ROOT.

Comment on attachment 69345 [details] [diff] [review] patch r=jag with the comments added we discussed.

checked in