Closed
Bug 124963
Opened 23 years ago
Closed 23 years ago
Table becomes excessively wide with XBL checkboxes
Categories
(Core :: XUL, defect)
Core
XUL
Tracking
()
RESOLVED
FIXED
mozilla1.0
People
(Reporter: bryner, Assigned: bryner)
References
Details
Attachments
(2 files)
190 bytes,
text/html
|
Details | |
5.96 KB,
patch
|
jag+mozilla
:
review+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Updated•23 years ago
|
bryner: could you attach a less complicated testcase? ;-), where is the maxelementsize for the XBL checkboxes computed?
Comment 2•23 years ago
|
||
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.
Assignee | ||
Comment 4•23 years ago
|
||
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.
Comment 5•23 years ago
|
||
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.
Comment 7•23 years ago
|
||
Thanks Bernd, --> XBL, CCing attinasi.
Assignee: karnaze → hyatt
Component: HTMLTables → XBL
QA Contact: amar → ian
Assignee | ||
Comment 8•23 years ago
|
||
Actually, this is a XUL box bug.
Component: XBL → XP Toolkit/Widgets: XUL
QA Contact: ian → jrgm
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 10•23 years ago
|
||
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 11•23 years ago
|
||
Comment on attachment 69345 [details] [diff] [review] patch r=jag with the comments added we discussed.
Attachment #69345 -
Flags: review+
Assignee | ||
Comment 12•23 years ago
|
||
checked in
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
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.
Description
•