Last Comment Bug 219693 - [FIXr]percentage height doesn't "work" inside overflow:hidden child of body
: [FIXr]percentage height doesn't "work" inside overflow:hidden child of body
: regression, testcase
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: x86 All
: P1 normal (vote)
: mozilla1.6alpha
Assigned To: Boris Zbarsky [:bz] (TPAC)
: Hixie (not reading bugmail)
: 219606 220545 221163 (view as bug list)
Depends on: 69355
  Show dependency treegraph
Reported: 2003-09-19 05:50 PDT by Peter Gruendler
Modified: 2003-10-16 21:39 PDT (History)
13 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

testcase (185 bytes, text/html)
2003-09-19 21:56 PDT, Andrew Schultz
no flags Details
Possible fix (11.05 KB, patch)
2003-10-05 00:53 PDT, Boris Zbarsky [:bz] (TPAC)
no flags Details | Diff | Splinter Review
Oops, this is the patch to look at (8.61 KB, patch)
2003-10-05 00:55 PDT, Boris Zbarsky [:bz] (TPAC)
dbaron: review+
dbaron: superreview+
Details | Diff | Splinter Review

Description Peter Gruendler 2003-09-19 05:50:16 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030903 Firebird/0.6.1+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030917 Firebird/0.6.1+

at some build later than 20030903, definitely in 20030917, firebird started
using only part of the drawpane for the site
This is documented with screenshots in
It was confirmed in Windows 2000 SP4 and in Windows XP SP1.

Reproducible: Always

Steps to Reproduce:
1. display the page ;-)

Actual Results:  

Expected Results:  
use the whole drawpane

Comment 1 Peter Gruendler 2003-09-19 06:13:35 PDT
20030917 is actually the first build containing this bug.
Comment 2 2003-09-19 13:44:10 PDT
This also happened in Mozilla-Browser (I have seen the bug with linux builds 
091622 and 091905) so it is probably a Gecko bug. Should this be reported as a
different bug for MozillaBrowser too?
Comment 3 2003-09-19 15:41:09 PDT
Changing product as this looks like a layout bug.
Comment 4 Andrew Schultz 2003-09-19 21:14:14 PDT
this regressed between linux trunk 2003091605 and 2003091622 (according to
Johann), suggesting bug 69355

Comment 5 Andrew Schultz 2003-09-19 21:56:36 PDT
Created attachment 131784 [details]

<body style="overflow:hidden;">
  <table border="1" height="100%"><tr><td>&nbsp;</td></tr></table>

with linux trunk 2003091822, the table is small.  with older builds, the table
spans the height of the window.  an iframe by itself behaves similarly.

was the behavior buggy before or after bug 69355?
Comment 6 2003-09-22 02:02:53 PDT
This should get some added priority IMO since it breaks a site that is visited
by thousands of Mozilla users (according to a poll on that site). It definitely
should not be in the 1.5 release or a lot of people will be very unhappy with
Comment 7 2003-09-22 02:13:03 PDT
oops, this is not in the 1.5 branch, sorry for the spam.
Comment 8 Boris Zbarsky [:bz] (TPAC) 2003-09-23 06:31:10 PDT
David, looks like that broke some of those ugly quirks hacks for 100%-height
Comment 9 Jesse Ruderman 2003-09-27 16:07:26 PDT
This bug also breaks, which has a
height:100% textarea inside an overflow:hidden body.
Comment 11 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2003-09-28 11:24:56 PDT
*** Bug 220545 has been marked as a duplicate of this bug. ***
Comment 12 Jesse Ruderman 2003-09-28 22:44:26 PDT
*** Bug 219606 has been marked as a duplicate of this bug. ***
Comment 13 Boris 'pi' Piwinger 2003-09-29 03:37:35 PDT
Adding for he might install a workaround at the site.

Comment 14 christoph richter 2003-09-29 04:11:40 PDT
who pays for the time working on???
we now make a reprogramming for bug #204719.
this took quite a week, because we have to change all the structure in the 
i would really appreciate, that such bugs are solved in Mozilla. i would help 
as much as i can.
btw. thanks to adding me to such bugs where is namend.
Comment 15 Boris Zbarsky [:bz] (TPAC) 2003-10-01 00:56:54 PDT
I'd say that working around a bug in a pre-alpha build of Mozilla is hardly
worth anyone's time... especially as we _do_ want to get this bug fixed on the
Mozilla side before 1.6....
Comment 16 Boris Zbarsky [:bz] (TPAC) 2003-10-03 15:49:50 PDT
*** Bug 221163 has been marked as a duplicate of this bug. ***
Comment 17 Boris Zbarsky [:bz] (TPAC) 2003-10-04 23:49:39 PDT
Comment 10 is not about this bug, as far as I can tell.  This bug is a
regression in quirks mode percent heights, while comment 10 is about a
standards-mode page.  In fact, the layout of the page is correct with a current
build (<body> is overflow:hidden, and all the content overflows, since it's all
absolutely positioned and the body height is not set).
Comment 18 Boris Zbarsky [:bz] (TPAC) 2003-10-05 00:53:14 PDT
Created attachment 132662 [details] [diff] [review]
Possible fix

This seems to fix the testcase, all urls linked from this bug that show the
quirks regression, and various variations on the testcase that I've tested (eg
setting overflow on <html>, setting overflow on <body> and a style height on
<html>, setting overflow and a style height on <body>, etc.)  I've also tested
the testcases in bug 85016 and its dependencies, and none of those are
Comment 19 Boris Zbarsky [:bz] (TPAC) 2003-10-05 00:55:48 PDT
Created attachment 132663 [details] [diff] [review]
Oops, this is the patch to look at

Some extra stuff snuck into that first diff....
Comment 20 Boris Zbarsky [:bz] (TPAC) 2003-10-05 01:01:12 PDT
Comment on attachment 132663 [details] [diff] [review]
Oops, this is the patch to look at

David, would you review?  The basic idea here is to

1)  Ignore the scrolledContent area frames

2)  Look at scrollframes in addition to block and area frames when looking for
a containing block with non-auto height (instead of just killing the loop when
they are reached).

Since in the testcase <body> is in fact a scrollframe, not a blockframe, I've
had to change the firstBlockRS/firstAreaRS thing to just keep pointers to
generic block/area/scrollframe ancestors.  The rest of the patch is just
propagation of that change through the function and elimination of .get() calls
on nsCOMPtrs.
Comment 21 David Baron :dbaron: ⌚️UTC-7 (busy September 14-25) 2003-10-05 16:44:30 PDT
Comment on attachment 132663 [details] [diff] [review]
Oops, this is the patch to look at

r+sr=dbaron.  Running the regression tests could be useful here...
Comment 22 Boris Zbarsky [:bz] (TPAC) 2003-10-05 20:57:37 PDT
Well, at least the regression tests run on Linux again as a result of this bug... ;)

Patch passes regression tests and is checked in.
Comment 23 Boris Zbarsky [:bz] (TPAC) 2003-10-05 22:00:47 PDT
Reopen for now; I accidentally checked in on red, and have backed the patch out...
Comment 24 Boris Zbarsky [:bz] (TPAC) 2003-10-05 22:09:53 PDT
To me.  I've added the testcase to the regression tests, by the way.
Comment 25 Boris Zbarsky [:bz] (TPAC) 2003-10-06 07:27:38 PDT
Comment 26 Boris Zbarsky [:bz] (TPAC) 2003-10-16 21:39:28 PDT
This caused bug 221784 

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