666 bytes, text/html
549 bytes, text/html
610 bytes, text/html
555 bytes, text/html
17.50 KB, image/png
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.
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
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.
(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.
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.
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.
14 years ago
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?
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
Last Resolved: 10 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
Is this still an issue ?
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...).
You need to log in before you can comment on or make changes to this bug.