368621 - [reflow branch] <table height="100%"> leads to page being tens of millions of pixels tall, and heights change when I focus a link

Status: RESOLVED FIXED

(Core :: Layout: Tables, defect)

Description

[jan klopper]

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

Comment 1

[Jesse Ruderman]

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.

Comment 2

[Jesse Ruderman]

Attachment: testcase (clicking makes heights increase) (standards mode)

Clicking the button makes the tables' heights increase.

Comment 3

[Jesse Ruderman]

Attachment: same testcase in quirks mode

Comment 4

[jan klopper]

Now i think of this,

Is this the same bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=363496

Comment 5

[doctor__j]

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.

Comment 6

[David Baron :dbaron:]

It's already marked as blocking bug 300030, i.e., known to have been caused by that checkin.

Comment 8

[Jesse Ruderman]

This bug might be interfering with my testing.

Comment 9

[Serge Gautherie (:sgautherie)]

(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.

Comment 10

[Chris Lawson (gone)]

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

Comment 11

[David Baron :dbaron:]

The patch in bug 381507 fixes the testcase.

Comment 13

[David Baron :dbaron:]

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.

Comment 14

[David Baron :dbaron:]

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...

Comment 15

[Daniel Holbert [:dholbert]]

(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.

Comment 16

[Jeff Walden [:Waldo]]

Sounds like this is tested by bug 381507 already.