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

NEW
Unassigned

Status

()

Core
Layout: Tables
13 years ago
5 years ago

People

(Reporter: Lutz Schwarz, Unassigned)

Tracking

({testcase})

Trunk
x86
Windows XP
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments, 1 obsolete attachment)

(Reporter)

Description

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

Comment 1

13 years ago
Created attachment 183987 [details]
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

Updated

13 years ago
Keywords: testcase

Comment 3

13 years ago
Created attachment 185048 [details]
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.

Comment 4

13 years ago
(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.

Comment 5

13 years ago
Is this still an issue?
Yes, this is still an issue.

Comment 7

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

Comment 8

13 years ago
Created attachment 192895 [details]
simple example

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.
Attachment #192895 - Attachment is obsolete: true
Created attachment 195132 [details]
Testcase2 standards mode

This doesn't happen in standards mode, where percentage height is treated as
height: auto in this example. So this is a quirks issue.
Created attachment 195134 [details]
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?
(Reporter)

Comment 11

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

Comment 12

13 years ago
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.
(Reporter)

Comment 13

13 years ago
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).

Comment 14

12 years ago
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

Comment 15

9 years ago
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

Comment 16

9 years ago
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
Last Resolved: 9 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 19

9 years ago
Created attachment 392927 [details]
the second scrollbar should not appear

Comment 20

9 years ago
comment 16 is bogus

Updated

9 years ago
Whiteboard: closeme 2009-08-01

Comment 21

5 years ago
Is this still an issue ?
Keywords: qawanted
The second scrollbar is still appearing for me, so I think this is still an issue.

Comment 23

5 years ago
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
(Reporter)

Comment 24

5 years ago
Thank you.
FYI: Opera V12.15 and Chrome Version 28.0.1500.72 are showing testcase #1 as expected (IE9 is half the way...).
You need to log in before you can comment on or make changes to this bug.