Open Bug 294680 Opened 19 years ago Updated 2 years ago

wrong layout calculation for overflow:scroll/auto/hidden if height/width is relative value

Categories

(Core :: Layout: Tables, defect)

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

Tracking

()

People

(Reporter: schwarz.cgs, Unassigned)

Details

(Keywords: testcase)

Attachments

(5 files, 1 obsolete file)

Reporter's testcase
666 bytes, text/html
Details
Maybe simpler testcase
549 bytes, text/html
Details
Testcase2 standards mode
610 bytes, text/html
Details
Testcase2 quirks mode
555 bytes, text/html
Details
the second scrollbar should not appear
17.50 KB, image/png
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

<!--
    This bug applies to elements that
    * have an overflow attribute value of scroll, auto or hidden AND 
    * have their height/width defined as a relative value (%, en, ...)
    The layout calculation for those elements account for the unclipped
    size of the element although the visible area of the element isn't that big.
    This behaviour may be ok for "overflow:none" but makes no sense for
    other overflow types.
    Surprisingly it does not happen if height/width is defined as
    absolute values (px, cm, ...)
-->

<html>
<body style="margin:0; background-color:red;">

<table cellpadding="0" cellspacing="0" style="width:100%; height:100%">
    <tr style="height:1; background-color:cyan;">
	<td id="info">top</td>
    </tr>
    <tr>
	<td valign="top">
	    <div id="bug" style="height:80%;
			width:100%;
			overflow:auto;
			background-color:green;
			">
		1 <br>2 <br>3 <br>4 <br>5 <br>6 <br>7 <br> 8 <br>9 <br> 10
		If this line "virtually" touches the bottom blue box, the
		green area's height will no longer shrink.
	    </div>
	</td>
    </tr>
    <tr style="height:1; background-color:blue;">
	<td>bottom</td>
    </tr>
</table>

</body>
</html>


Reproducible: Always

Steps to Reproduce:
1. open the supplied html code in mozilla
2. shrink the browser window's height until the green area got scroll bars
3. Go on shrinking the browser window's height

Actual Results:  
While descreasing the browser window's height, the green area stops shrinking at
the 8th line. At this point, the browser window got a scroll bar. On further
shrinking the window, the blue box at the bottom moves out of the browser window.


Expected Results:  
While descreasing the browser window's height, the green area should not stop
shrinking. The browser window should not get scroll bars. The blue box at the
bottom should not move out of the browser window.

For this scenario, MSIE 6 behaves as expected.
Attached file Reporter's testcase — 

    
    

    
  
Looks like a tables issue (since the table is what makes the body be bigger than
the viewport here).
Component: Layout → Layout: Tables
QA Contact: layout → layout.tables
Keywords: testcase

    
    

    
  

      
      
      
      

        Attached file
          
        Maybe simpler testcase
        — 
      

    


  
I think I´ve run into this bug and can provide a simpler testcase. Deer Park
Alpha 1 extends the whole viewport, whereas Firefox 1.0 displays a scrollbar in
the div. The bug magically disappears in Deer Park Alpha 1 when you remove the
table around the div.

    
    

    
  
(In reply to comment #3, myself)
The bug my testcase shows seems to have been bug #295459 as it is fixed in
today´s build.

    
    

    
  
Is this still an issue?

    
    

    
  
Yes, this is still an issue.
Keywords: qawanted

    
    

    
  
The browser seems to truncate right-aligned text from the right instead of from
the left if the box (contents) is too wide and if the CSS overflow property is
set to hidden.  This seems true in all current Gecko-based browsers, and also in
Opera, and does not depend on whether the width is relative or absolute.

Not sure if this is the right bug to file it under.



    
    

    
  

      
      
      
      

        Attached file
          
        simple example (obsolete)
        — 
      

    


  
The enclosed HTML file shows the problem.
Reproduce by resizing the browser window and seeing
that the right hand end of the left (blue) column changes whenever
there isn't enough room to right-align the text.

    
    

    
  


  
This doesn't happen in standards mode, where percentage height is treated as
height: auto in this example. So this is a quirks issue.

    
    

    
  

      
      
      
      

        Attached file
          
        Testcase2 quirks mode
        — 
      

    


  
So it seems that when the height of the viewport is bigger than the intrinsic
(I hope I use the right term here) height of the green div, then the resulting
height of the green div becomes appr. 50% of the height of the viewport.
But when the intrinsic height of the green div is bigger than the height of the
viewport, then the resulting height seems to become appr. 50% of the intrinsic
height of the green div.
This is not what IE6 is doing. IE6 is always doing the first thing, the
resulting height of the green div always becomes 50% of the viewport.
So the question is, should Mozilla do the same thing here?

    
    

    
  
Answer to question in comment #10: Yes.

I did furter tests and it seems that the problem occurs only (or at least...) if
the containing block (the block that contains the "div-with-overflow:scroll"
block) is a table cell AND the div has a relative (e.g. percentage) height. So -
according to specs - the height of the div is computed in terms of the table
cell's height, which in turn tries to compute its own height depending on its
descendants, namely the div. At this point, the unclipped(!) height of the div
content is used by the table cell, thereby not accounting for the fact, that the
div - due to its overflow:scroll attribute - does not need space for its
complete content. Would the div have an absolute height (e.g. 123px and still
overflow:scroll, of course) the table cell really uses exactly this height
ignoring the unclipped height of the div (this is what I expect).

The fix might be, to ignore the unclipped height of the div not only in case of
absolute height values but ALSO in case of relative (percentage) height values,
as long the div also has an overflow:scroll, auto or hidden attribute.

Hmm, ok, more conditions must be true to apply that fix:
Because the height of the div and height of the table cell are declared to be
relative to each other, there must be a way to compute the table cell's height
on a different way. This is possible (in quirks mode only?) if table height has
been specified and by using -moz-box-align:stretch functinality.

A further note: in a real application, I would set the height of the
"div-with-overflow:scroll" to be 100% (of the containing table cell) rather than
to 80% as in my 1st test case.

    
    

    
  
another manifestation, much simpler to demonstrate is:

<html>
<body>
<div style="width:400;height:400; background-color: green; position:relative;
overflow:scroll; border:10px solid black;">
 <div style="width:100%;height:100%; background-color: red; position:absolute;
border: 10px solid blue; -moz-box-sizing: border-box;">
 </div>
</div>
</body>
</html>

check out what it looks like in FF1.0, and IE, then check out FF1.5
Should be: black border box.  inside, a scrollbarred area, which has a blue
border with a red interior.

ff1.5 sizes the inner box (as shown by blue border) too large.


BTW OS for me is Linux, so the OS should be changed.

    
    

    
  
As far as I can see, there is no problem with the html code in comment #12.
I used FF1.0.7 and it looks as I would expect. Except for the fact, that the
scroll bars are rendered 'enabled' although there is really nothing to scroll
(inner div is defined to have 100% size of the enclosing div, so it will always
fit and does not produce overflow that could be scrolled).

    
    

    
  
really frustrating.

the bug still exists in FF1.5 release.  it is slightly different, but still quite buggy.

this affects all of my company's webapps to the point where we will be forced to forbid the use of FF1.5.

it has no workaround, unless you allow a css extension:

width: 100% - (width of a scrollbar iff vert. scrollbar is displayed)
height: 100% - (height of a scrollbar iff horiz. scrollbar is displayed)

this behavior is inconsistent with FF1.0 AND IE

at least if someone could CONFIRM the bug it would have a chance



    
    

    
  
Do you still see this problem using Firefox 3.5?  Please update the bug, and close/alter bug if appropriate.
Whiteboard: closeme 2009-08-01

    
    

    
  
This is WFM with a current nightly

    
    

    
  
No reply, INCO. Please reopen if you are seeing this in Firefox 3.5.2 or later in Firefox safe mode and a new profile with the latest plugins.
http://support.mozilla.com/kb/Safe+Mode
http://support.mozilla.com/kb/Profiles
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → INCOMPLETE

    
    

    
  
I can still see the bug in current trunk build.
This bug can never be resolved as INCOMPLETE, since this one has clear and concise testcases that show the issue.
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---

    
    

    
  
comment 16 is bogus

    
  
Whiteboard: closeme 2009-08-01

    
    

    
  
Is this still an issue ?
Keywords: qawanted

    
    

    
  
The second scrollbar is still appearing for me, so I think this is still an issue.

    
    

    
  
Mozilla/5.0 (Windows NT 5.1; rv:23.0) Gecko/20100101 Firefox/23.0
Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20130724 Firefox/24.0
Mozilla/5.0 (Windows NT 5.1; rv:25.0) Gecko/20130723 Firefox/25.0

I was able to reproduce this issue on FF 23 beta 8 (Build ID: 20130722172257), Nightly 25.0a1 (Build ID: 20130723030205), Aurora 24.0a2 (Build ID: 20130724004003) with the attached testcases from comment 1 and comment 10.
Based on comment 22 and my testing results, setting the status to New.
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: alexandra.lucinet

    
    

    
  
Thank you.
FYI: Opera V12.15 and Chrome Version 28.0.1500.72 are showing testcase #1 as expected (IE9 is half the way...).

    
  
Severity: normal → S3

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: