Closed Bug 368621 Opened 17 years ago Closed 17 years ago
[reflow branch] <table height="100%"> leads to page being tens of millions of pixels tall, and heights change when I focus a link
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9a2pre) Gecko/20070129 Minefield/3.0a2pre Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9a2pre) Gecko/20070129 Minefield/3.0a2pre height goes completely off the scale in current ff nightly, so does clicking on a link inside such a mangled table. Click on the link and notice the problem, this is a regression from the last gecko, and probably a regression within 1.8. Reproducible: Always Steps to Reproduce: 1. click the link (using ff 3.0 minefield nightly builds) 2. see the mis formed height 3. try and click any of the thumbnail links. Actual Results: The height of the table rows is wrong, Clicking on a link triggers some sort of refresh, or redraw causing the page to scroll a large portion, but disabling the click. Expected Results: render as in moz 2.0
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → Trunk
I have a simple testcase demonstrating the "when I click a link, the height of some stuff changes" issue. Is the other issue ("the page's height is computed as about 30 million pixels") likely to be due to the same bug in the code? If not, I can try to make a simple testcase for that as well.
Status: UNCONFIRMED → NEW
Component: Layout → Layout: Tables
Ever confirmed: true
OS: Linux → All
QA Contact: layout → layout.tables
Hardware: PC → All
Summary: height goes completely off the scale in current ff nightly, so does clicking on a link inside such a mangled table → <table height="100%"> leads to page being tens of millions of pixels tall, and heights change when I focus a link
Clicking the button makes the tables' heights increase.
Now i think of this, Is this the same bug: https://bugzilla.mozilla.org/show_bug.cgi?id=363496
This bug happens between trunk builds 2006-12-07-08 and 2006-12-08-08. Very much similar to the case of Bug 370525, which happens between the two builds. That may suggest the two bugs originate from the same checkin.
It's already marked as blocking bug 300030, i.e., known to have been caused by that checkin.
This bug might be interfering with my testing.
(In reply to comment #5) > This bug happens between trunk builds 2006-12-07-08 and 2006-12-08-08. Very > much similar to the case of Bug 370525, which happens between the two builds. They look like duplicates to me.
Flags: blocking1.9? → blocking1.9+
David or Jesse, is this definitely a dupe (per comment 9), or is there a reason it's separate? (If there is, I apologise for the bugspam, but it's not at all clear from the discussion thus far that this is indeed a separate issue.) cl
Fixed by checkin of bug 381507, although I'm not sure that the site rendering is correct. It's no longer extremely tall, and the testcases don't grow anymore.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Actually, reopening; the page is still broken relative to Firefox 2; further testcases are needed, although maybe they should be filed as a separate bug report...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #14) The remaining problem (page being broken vs. FF 2.0) is a duplicate of bug 364124 and bug 370525. There are testcases for each of those bugs at their pages.
Status: REOPENED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
Sounds like this is tested by bug 381507 already.
You need to log in before you can comment on or make changes to this bug.