489906 - "new testcase" from bug 368603 is broken again

Status: RESOLVED WORKSFORME

(Core :: Layout: Tables, defect)

Description

[Daniel Holbert [:dholbert]]

I just discovered that "new testcase" (attachment 270817 [details]) from bug 368603
is now broken in mozilla-central nightlies.  (I'm filing a new bug rather than reopening that one, because the original site and testcases on that bug all work fine in mozilla-central -- it's just the one final testcase that's broken.)

STEPS TO REPRODUCE:
 1. Load URL
 2. Click the button

EXPECTED RESULTS: Nothing should change
ACTUAL RESULTS: Colored table grows in height

mozilla-central shows actual results:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090423 Minefield/3.6a1pre

Firefox 3.0.9 shows expected results:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.9) Gecko/2009042113 Ubuntu/9.04 (jaunty) Firefox/3.0.9

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Here's a slightly cleaned-up testcase (which still fails on mozilla-central but passes on 3.0.9)

Comment 2

[Ryan VanderMeulen [:RyanVM]]

When trying to find a regression range with dholbert, I initially discovered that this broke between the 2008-09-05 and 2008-09-06 Win32 nightlies. However, dholbert couldn't reproduce the regression range with the corresponding Linux nightlies. However, he was able to reproduce between the 2008-09-07 and 2008-09-08 nightlies. I was also able to confirm that it worked again on 09-07 and broke on 09-08. Looking at the regression range below, we get a nice clue:
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-09-06+00%3A00%3A00&enddate=2008-09-08+04%3A00%3A00

Bug 243519 was initially landed after the 09-06 Linux nightly was spun, but before the Win32 nightly. It was later backed out and re-landed on 09-07, in time for both 09-08 nightlies. Therefore, it seems likely to be the cause of the regression.

dholbert is doing local builds now before and after it landed to verify.

Comment 3

[Daniel Holbert [:dholbert]]

Confirmed -- changeset b7bcdd009540 shows working/expected results, & changeset 679778dd198f shows buggy results.  So, regression from bug 243519.

Comment 4

[Daniel Holbert [:dholbert]]

WFM in today's nightly:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091026 Minefield/3.7a1pre

Still broken in 1.9.1, though:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3) Gecko/20091020 Ubuntu/9.10 (karmic) Firefox/3.5.3

(I tested both "testcase 1" & attachment 270817 [details] from bug 368603)

Comment 5

[Daniel Holbert [:dholbert]]

Fixed range:
BROKEN:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090623 Minefield/3.6a1pre
WORKING:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090624 Minefield/3.6a1pre

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c575412d976a&tochange=5fe89f2c22f0

I'm not immediately sure which push there would've fixed this, though... maybe bug 495385?

Comment 6

[Daniel Holbert [:dholbert]]

Yeah -- it makes sense that bug 495385 would neutralize the effect of testcase 1's button. (since the button just inserts some whitespace into a div, and bug 495385 would keep us from making a text frame for that whitespace)