Closed Bug 30692 Opened 25 years ago Closed 23 years ago

Cell content sized with height:x% does not resize

Categories

(Core :: Layout: Tables, defect, P3)

Product:
Core
Component:
Layout: Tables
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.7

People

(Reporter: keith.lesch, Assigned: karnaze)

References

Details

(Keywords: testcase, Whiteboard: [awd:tbl] PATCH CANDIDATE_094)

Attachments

(6 files, 1 obsolete file)

Textarea does not size its height correctly.
197 bytes, text/html
Details
Scratch that last attachment! This one shows the case. :-)
199 bytes, text/html
Details
better testcase
1.06 KB, text/html
Details
patch to fix the bug
1.78 KB, patch
alexsavulov
: review+
attinasi
: superreview+
Details | Diff | Splinter Review
correct patch
797 bytes, patch
karnaze
: review+
karnaze
: superreview+
Details | Diff | Splinter Review
testcase - implicit cell height
234 bytes, text/html
Details 
See title and attachment.  I am referring to a textarea that is inside of a 
specifically sized element, in this case a table.
The bug occurs with any cell content, not just TEXTAREA.
I'm going to attach another testcase which shows that:
- % values don't work for the height but they work for the width.
- absolute units for the height work correctly.

Reassigned to HTML Tables.
Assignee: pierre → karnaze
Status: UNCONFIRMED → NEW
Component: Style System → HTMLTables
Ever confirmed: true
Summary: TEXTAREA sized with height:x% does not resize → Cell content sized with height:x% does not resize
Attached file better testcase — 

    
    

    
  
Fixed by using the cell rather than the cell's inner block as the percentage 
base in nsHTMLReflowState.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Target Milestone: --- → M16

    
    

    
  
Sorry for the delay...haven't been able to work with Moz lately.  Looks good to 
me.
Status: RESOLVED → VERIFIED

    
    

    
  
Regression?  The 3rd attachment now fails.  Bug #1 in the test case fails with
height:x% on the textarea; the P still adjusts its height correctly.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

    
  
Keywords: testcase

    
    

    
  
testcase 2 and 3 produce an assertion

    
    

    
  
*** Bug 63534 has been marked as a duplicate of this bug. ***

    
    

    
  
adding hixie to cc

    
    

    
  
*** Bug 52525 has been marked as a duplicate of this bug. ***

    
  
Target Milestone: M16 → ---

    
    

    
  
Moving to m0.9.1
Status: REOPENED → ASSIGNED
Target Milestone: --- → mozilla0.9.1

    
    

    
  
cc spam

    
    

    
  
QA contact update
QA Contact: chrisd → amar

    
    

    
  
Moving to m0.9.3
Target Milestone: mozilla0.9.1 → mozilla0.9.3

    
    

    
  
Missed 0.9.3.
Target Milestone: mozilla0.9.3 → mozilla0.9.4

    
  
Target Milestone: mozilla0.9.4 → mozilla0.9.5

    
  
Blocks: 97138

    
    

    
  
reassigning to m0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6

    
  
Whiteboard: [awd:tbl]

    
    

    
  


  

    
  
Whiteboard: [awd:tbl] → [awd:tbl] PATCH

    
    

    
  
Comment on attachment 56654 [details] [diff] [review]
patch to fix the bug

r= alexsavulov

        Attachment #56654 -
        Flags: review+

    
    

    
  
Comment on attachment 56654 [details] [diff] [review]
patch to fix the bug

sr=attinasi

        Attachment #56654 -
        Flags: superreview+

    
    

    
  
The patch is in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
Whiteboard: [awd:tbl] PATCH → [awd:tbl] PATCH CANDIDATE_094

    
    

    
  
I'm still seeing the first textarea in "better testcase" collapsed on 2001111603
Win98.  Regression?

    
    

    
  
reopening

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
  
Status: REOPENED → ASSIGNED

    
    

    
  


  

    
  
Target Milestone: mozilla0.9.6 → mozilla0.9.7

    
  

        Attachment #58540 -
        Flags: review+

    
    

    
  
Comment on attachment 58540 [details] [diff] [review]
additional patch to deal with incremental reflow

sr=attinasi

        Attachment #58540 -
        Flags: superreview+

    
    

    
  
Comment on attachment 58540 [details] [diff] [review]
additional patch to deal with incremental reflow

I attached the wrong patch

        Attachment #58540 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        correct patch
        — 
          — Splinter Review
      

    


  

    
    

    
  
Comment on attachment 58691 [details] [diff] [review]
correct patch

attinasi and alexsavulov reviewed this with me.

        Attachment #58691 -
        Flags: superreview+

        Attachment #58691 -
        Flags: review+

    
    

    
  
The additional patch is in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED

    
    

    
  


  
Almost there, but not quite finished.  This testcase shows how the bug will
still appear if there is no explicit height on the table, row, or cell. 
Rather, the height is determined by other cells in the same row.  IE 4 renders
it correctly.

2001112203 Win98

    
    

    
  
Ok Greg, bug 112651 covers the remaining issue.

    
    

    
  
 Looks like this bug is fixed. Marking verified.
Status: RESOLVED → VERIFIED

    
    

    
  
Agreed!  Thanks for your work all.  Trying out Mozilla 0.9.9 now on Win2k and it
looks great...and seems to be running much faster than 0.9.7.

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: