Closed
Bug 40283
Opened 24 years ago
Closed 24 years ago
Table miscalculation with cell width = 100% , NoWrap, and <input>
Categories
(Core :: Layout: Tables, defect, P1)
Tracking
()
VERIFIED
FIXED
M18
People
(Reporter: pabloa, Assigned: buster)
References
()
Details
(Keywords: testcase, Whiteboard: [nsbeta2+] [6/15] wdormann@crosswinds.net)
Attachments
(3 files)
164 bytes,
text/html
|
Details | |
136 bytes,
text/html
|
Details | |
491 bytes,
patch
|
Details | Diff | Splinter Review |
I can not to check/uncheck a checkbox form. Its name is 'Mostrar mensajes ampliados'. Steps to Reproduce: 1) Go to http://www.patagon.com.ar/forlf.asp?fId=2&pi=1&ci=20&i=2&f=18&o= fechaHora&s=desc&a=false&rnd=0.6461603 2) Try to click in 'Mostrar mensajes ampliados' in the upper right corner. Actual Results: I can not click in it. Expected Results: I need to click it. Build Date & Platform: 2000052208 Windows NT Version Additional Information: I try it on Windows NT 4 Englsi Workstation + SP 5
Tested on Linux M16 2000-052208: There's something odd there: Only parts of the checkbox is visible. Clicking IN the visible checkbox area has no effect. However: Clicking on the edge/corner of it does toggle it checked/unchecked.
Making simplified test case. Looks like a layout problem, actually.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: makingtest
OS: Windows NT → All
Whiteboard: wdormann@crosswinds.net
The test case is a table with 2 cells. --------------------------------------- | width=100% | nowrap "text" <input> | | | | --------------------------------------- It appears that in such a case, the <input> is not considered in the calculation for the cell width. In my example, the checbox is not clickable because it falls on (under?) the border of the table. Other types of <input> give the same problem.
Component: HTML Form Controls → HTMLTables
Keywords: makingtest → testcase
Summary: The checkbox form is not checkeable → Table miscalculation with cell width = 100% , NoWrap, and <input>
Comment 6•24 years ago
|
||
rod, can you do a little research and if it is not a <input> problem then reassign to buster. The problem is that block 011F2204 is returning a max element width of 1005 (#1 below) but then when it is reflowed with that as an avail width it is returning a desired width of 1305. The block or its contents appear to be not right the first time. TO::Rfl en 011F1F50 rea=0 av=(8940,UC) comp=(0,0) count=0 T::Rfl en 011F1FA4 rea=0 av=(8940,UC) comp=(UC,UC) count=1 TRG::Rfl 011F2010 rea=0 av=(UC,UC) comp=(UC,UC) count=2 TR::Rfl en 011F2054 rea=0 av=(UC,UC) comp=(UC,UC) count=3 TC::Rfl 011F209C rea=0 av=(UC,UC) comp=(UC,UC) count=4 Area::Rfl en 011F20F8 rea=0 av=(UC,UC) comp=(UC,UC) count=5 Area::Rfl ex 011F20F8 des=(0,0) maxElem=(0,0) TC::Rfl ex 011F209C des=(165,180) maxElem=(165,180) TC::Rfl 011F21A8 rea=0 av=(UC,UC) comp=(UC,UC) count=6 Area::Rfl en 011F2204 rea=0 av=(UC,UC) comp=(UC,UC) count=7 Area::Rfl ex 011F2204 des=(1305,285) maxElem=(1005,285) // #1 TC::Rfl ex 011F21A8 des=(1485,465) maxElem=(1185,465) TR::Rfl ex 011F2054 des=(1770,0) maxElem=(1350,465) TRG::Rfl ex 011F2010 des=(UC,30) maxElem=(1350,465) TRG::Rfl 011F2010 rea=2 av=(8910,UC) comp=(8910,UC) count=8 TR::Rfl en 011F2054 rea=2 av=(8910,UC) comp=(8910,UC) count=9 TC::Rfl 011F209C rea=2 av=(7635,UC) comp=(7455,UC) count=10 Area::Rfl en 011F20F8 rea=2 av=(7485,UC) comp=(7485,UC) count=11 Area::Rfl ex 011F20F8 des=(7485,0) TC::Rfl ex 011F209C des=(7635,180) TC::Rfl 011F21A8 rea=2 av=(1185,UC) comp=(1005,UC) count=12 Area::Rfl en 011F2204 rea=2 av=(1005,UC) comp=(1005,UC) count=13 Area::Rfl ex 011F2204 des=(1305,285) // #2 TC::Rfl ex 011F21A8 des=(1185,465) TR::Rfl ex 011F2054 des=(8880,465) TRG::Rfl ex 011F2010 des=(8910,465) T::Rfl ex 011F1FA4 des=(8940,555) TO::Rfl ex 011F1F50 des=(8940,555)
Assignee: karnaze → rods
Comment 7•24 years ago
|
||
The problem is the line is not taking into account that it is in "nowrap" when it returns its max-element-size. It is incorrectly returning the MES of the largest frame it holds (which is fine for wrap mode), in this case the text "Check this:" which is 1005 twips wide (the input is 195 twips wide). BRS: setting compute-MES to 0 BRS: setting compute-MES to 0 has multiple monitor apis is 0 BRS: setting compute-MES to 0 BRS: setting compute-MES to 0 BRS: setting compute-MES to 0 BRS: setting compute-MES to 1 PASS1 Block(td)(0)@012057F4: line.floaters= band.floaterCount=0 nsBlockFrame::PostPlaceLine: 012057F4 setting line 0120587C MES 0 nsBlockFrame::PostPlaceLine block 012057F4 line 0120587C caching max width 0 nsBlockFrame::ReflowLine block 012057F4 line 0120587C setting aLine.mMaxElementWidth to 0 nsBlockFrame::CFS: 012057F4 returning MES 0 PASS1 Block(td)(0)@012057F4: max-element-size:0,0 desired:0,0 maxSize:1073741824,1073741824 block 012057F4 returning with maxElementSize=0,0 BRS: setting compute-MES to 1 PASS1 Block(td)(1)@01205900: line.floaters= band.floaterCount=0 PASS1 Block(td)(1)@01205900: old max-element-size=0,0 new=1005,285 (set wrong here) nsBlockFrame::PostPlaceLine: 01205900 setting line 01205A3C MES 1005 nsBlockFrame::PostPlaceLine block 01205900 line 01205A3C caching max width 1305 nsBlockFrame::ReflowLine block 01205900 line 01205A3C setting aLine.mMaxElementWidth to 1005 nsBlockFrame::CFS: 01205900 returning MES 1005 PASS1 Block(td)(1)@01205900: max-element-size:1005,285 desired:1305,285 maxSize:1073741824,10737 41824 block 01205900 returning with maxElementSize=1005,285 BRS: setting compute-MES to 0 BRS: setting compute-MES to 0
Assignee: rods → buster
Rod and Chris did great research: this should be easy to fix now.
Status: NEW → ASSIGNED
Priority: P3 → P1
Target Milestone: --- → M18
Assignee | ||
Comment 10•24 years ago
|
||
I've got the fix for this. Rod and Chris made it easy for me. Recommend nsbeta2+ for these reasons: 1) trivial fix, no risk 2) potentially effects many pages that use tables. it's a fix to the underlying block max-element-size measuring code that was just plain wrong in the case of nowrap being applied (via HTML attribute or CSS.) max-element-size is used by tables to determine the width of columns. if it's wrong, elements end up in the wrong place and/or columns end up with the wrong size.
Keywords: nsbeta2
Whiteboard: wdormann@crosswinds.net → wdormann@crosswinds.net [FIX IN HAND]
Assignee | ||
Comment 11•24 years ago
|
||
adding chris and rod to the cc list. can one of you please review the patch?
Assignee | ||
Comment 12•24 years ago
|
||
Comment 13•24 years ago
|
||
nsbeta2+ until 6/15.
Whiteboard: wdormann@crosswinds.net [FIX IN HAND] → [nsbeta2+] [6/15] wdormann@crosswinds.net [FIX IN HAND]
Assignee | ||
Comment 14•24 years ago
|
||
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Whiteboard: [nsbeta2+] [6/15] wdormann@crosswinds.net [FIX IN HAND] → [nsbeta2+] [6/15] wdormann@crosswinds.net
You need to log in
before you can comment on or make changes to this bug.
Description
•