bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

Table miscalculation with cell width = 100% , NoWrap, and <input>




Layout: Tables
18 years ago
18 years ago


(Reporter: Juan Pablo Alcaraz, Assigned: buster)




Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta2+] [6/15] wdormann@crosswinds.net, URL)


(3 attachments)



18 years ago
I can not to check/uncheck a checkbox form. Its name is 'Mostrar mensajes

Steps to Reproduce:

1) Go to http://www.patagon.com.ar/forlf.asp?fId=2&pi=1&ci=20&i=2&f=18&o=

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

Comment 1

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

Comment 2

18 years ago
Making simplified test case.   Looks like a layout problem, actually.
Ever confirmed: true
Keywords: makingtest
OS: Windows NT → All
Whiteboard: wdormann@crosswinds.net

Comment 3

18 years ago
Created attachment 9070 [details]
Simplified Testcase

Comment 4

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

18 years ago
Assignee: rods → karnaze

Comment 6

18 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

18 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 
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 
block 01205900 returning with maxElementSize=1005,285 
BRS: setting compute-MES to 0
BRS: setting compute-MES to 0
Assignee: rods → buster

Comment 8

18 years ago
Rod and Chris did great research: this should be easy to fix now.
Priority: P3 → P1
Target Milestone: --- → M18

Comment 9

18 years ago
Created attachment 10052 [details]
better test case derived from the first.  legal html, fewer elements

Comment 10

18 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]

Comment 11

18 years ago
adding chris and rod to the cc list.  can one of you please review the patch?

Comment 12

18 years ago
Created attachment 10053 [details] [diff] [review]
patch.  simply accounts for nowrap in computing maxElementWidth

Comment 13

18 years ago
nsbeta2+ until 6/15. 
Whiteboard: wdormann@crosswinds.net [FIX IN HAND] → [nsbeta2+] [6/15] wdormann@crosswinds.net [FIX IN HAND]

Comment 14

18 years ago
fix checked in
Last Resolved: 18 years ago
Resolution: --- → FIXED
Whiteboard: [nsbeta2+] [6/15] wdormann@crosswinds.net [FIX IN HAND] → [nsbeta2+] [6/15] wdormann@crosswinds.net

Comment 15

18 years ago
You need to log in before you can comment on or make changes to this bug.