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 http://derstandard.at. This is documented with screenshots in http://dapeda.at/firebird_derstandard.htm. It was confirmed in Windows 2000 SP4 and in Windows XP SP1. Reproducible: Always Steps to Reproduce: 1. display the page ;-) Actual Results: see http://dapeda.at/firebird_derstandard.htm Expected Results: use the whole drawpane none
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?
Changing product as this looks like a layout bug.
this regressed between linux trunk 2003091605 and 2003091622 (according to Johann), suggesting bug 69355 reassigning
Created attachment 131784 [details] testcase <body style="overflow:hidden;"> <table border="1" height="100%"><tr><td> </td></tr></table> </body> 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?
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 Mozilla.
oops, this is not in the 1.5 branch, sorry for the spam.
David, looks like that broke some of those ugly quirks hacks for 100%-height tables....
This bug also breaks http://www.squarefree.com/htmledit/, which has a height:100% textarea inside an overflow:hidden body.
From http://forums.mozillazine.org/viewtopic.php?t=26887: This bug also breaks http://www.messagelabs.com/viruseye/threats/
*** Bug 220545 has been marked as a duplicate of this bug. ***
*** Bug 219606 has been marked as a duplicate of this bug. ***
Adding webmaster@derStandard.at for he might install a workaround at the site. pi
heh. 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 mainframe. 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 derStandard.at is namend.
14 years ago
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).
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 regressed.
Created attachment 132663 [details] [diff] [review] Oops, this is the patch to look at Some extra stuff snuck into that first diff....
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 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...
Well, at least the regression tests run on Linux again as a result of this bug... ;) Patch passes regression tests and is checked in.
Reopen for now; I accidentally checked in on red, and have backed the patch out...
To me. I've added the testcase to the regression tests, by the way.
This caused bug 221784