Closed Bug 219693 Opened 21 years ago Closed 21 years ago

[FIXr]percentage height doesn't "work" inside overflow:hidden child of body


(Core :: Layout, defect, P1)






(Reporter: peter.gruendler, Assigned: bzbarsky)




(Keywords: regression, testcase)


(2 files, 1 obsolete file)

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

20030917 is actually the first build containing this bug.
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?
Ever confirmed: true
Changing product as this looks like a layout bug.
Component: General → Layout
Product: Firebird → Browser
Version: unspecified → Trunk
this regressed between linux trunk 2003091605 and 2003091622 (according to
Johann), suggesting bug 69355

Assignee: blake → other
Keywords: regression
OS: Windows 2000 → All
QA Contact: asa → ian
Attached file testcase
<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?
Keywords: testcase
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
Flags: blocking1.5+
Flags: blocking1.5+ → blocking1.5?
oops, this is not in the 1.5 branch, sorry for the spam.
Flags: blocking1.5? → blocking1.6a?
Summary: only part of the drawpane is used for rendering this site. → percentage height doesn't "work" inside overflow:hidden child of body
David, looks like that broke some of those ugly quirks hacks for 100%-height
This bug also breaks, which has a
height:100% textarea inside an overflow:hidden body.
*** Bug 220545 has been marked as a duplicate of this bug. ***
*** Bug 219606 has been marked as a duplicate of this bug. ***
Adding for he might install a workaround at the site.

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.
Depends on: 69355
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....
*** Bug 221163 has been marked as a duplicate of this bug. ***
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).
Attached patch Possible fix (obsolete) — Splinter Review
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
Some extra stuff snuck into that first diff....
Attachment #132662 - Attachment is obsolete: true
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.
Attachment #132663 - Flags: superreview?(dbaron)
Attachment #132663 - Flags: review?(dbaron)
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...
Attachment #132663 - Flags: superreview?(dbaron)
Attachment #132663 - Flags: superreview+
Attachment #132663 - Flags: review?(dbaron)
Attachment #132663 - Flags: review+
Well, at least the regression tests run on Linux again as a result of this bug... ;)

Patch passes regression tests and is checked in.
Closed: 21 years ago
Resolution: --- → FIXED
Reopen for now; I accidentally checked in on red, and have backed the patch out...
Resolution: FIXED → ---
Summary: percentage height doesn't "work" inside overflow:hidden child of body → [FIXr]percentage height doesn't "work" inside overflow:hidden child of body
To me.  I've added the testcase to the regression tests, by the way.
Assignee: other → bzbarsky
Priority: -- → P1
Target Milestone: --- → mozilla1.6alpha
Closed: 21 years ago21 years ago
Resolution: --- → FIXED
This caused bug 221784 
You need to log in before you can comment on or make changes to this bug.