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:188.8.131.52) Gecko/2009042113 Ubuntu/9.04 (jaunty) Firefox/3.0.9
Created attachment 374379 [details] testcase 1 Here's a slightly cleaned-up testcase (which still fails on mozilla-central but passes on 3.0.9)
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.
Confirmed -- changeset b7bcdd009540 shows working/expected results, & changeset 679778dd198f shows buggy results. So, regression from bug 243519.
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:184.108.40.206) Gecko/20091020 Ubuntu/9.10 (karmic) Firefox/3.5.3 (I tested both "testcase 1" & attachment 270817 [details] from bug 368603)
Status: NEW → RESOLVED
Last Resolved: 9 years ago
OS: Linux → All
Resolution: --- → FIXED
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?
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)
Depends on: 495385
You need to log in before you can comment on or make changes to this bug.