Bug 45097 – Snow Leopard Release Tests buildslave failing on fast/css/display-none-inline-style-change-crash

• Component: CSS
• Status: RESOLVED FIXED

[Matthew Willis (lilmatt)]

The Snow Leopard Release Tests buildslave has been failing on fast/css/display-none-inline-style-change-crash since Tuesday night.

http://build.webkit.org/waterfall?show=SnowLeopard%20Intel%20Release%20(Tests)&last_time=1283326000

The test is failing, not because the original bug for which it was written has returned, but because of this now (unexpectedly) appearing in the output.

> ALERT: 1 rule(s) were returned from getMatchedCSSRules, expected zero.

build 16778 appears to work and 16779 doesn't.  There's a pretty major change w/r/t CSS in r66577.

[Matthew Willis (lilmatt)]

(In reply to comment #0)
> build 16778 appears to work and 16779 doesn't.

Clarification: build 16778 passes the test and 16779 doesn't.  The builds otherwise "work".

[Matthew Willis (lilmatt)]

I searched the code base for the string found in the output
> were returned from getMatchedCSSRules

I only found it in fast/css/disabled-author-styles.html
However the test that's failing is fast/css/display-none-inline-style-change-crash.html

There don't appear to be any common tag IDs or function names.

Somehow the output from one test is leaking into the other, and with some frequency!

[Matthew Willis (lilmatt)]

Note that the tests are adjacent to each other in alpha order, so perhaps one test's output is being attributed to the following test. Perhaps the FIRST test is the one that's failing, and there's a bug in the testing framework that is letting the output "leak" into the next test.

[Matthew Willis (lilmatt)]

eseidel suggested CCing the authors of the two tests (hyatt and mitz)

Link to actual failed test output diff (cause it sucked to find it): http://bit.ly/agx1fs

[Matthew Willis (lilmatt)]

Created attachment 66400 [details]
Attempt to fix flaky test by adding layoutTestController.waitUntilDone() and ...notifyDone()

[Eric Seidel (no email)]

Hmm..  I suspect it's a more recent regression.  The timeout, if anything, will just make it fail more consistently as the right test instead of bleeding into the next test.

[Eric Seidel (no email)]

Comment on attachment 66400 [details]
Attempt to fix flaky test by adding layoutTestController.waitUntilDone() and ...notifyDone()

I'm all for making this test more reliable.  So lets give this a shot.

[Eric Seidel (no email)]

Comment on attachment 66400 [details]
Attempt to fix flaky test by adding layoutTestController.waitUntilDone() and ...notifyDone()

Clearing flags on attachment: 66400

Committed r66684: <http://trac.webkit.org/changeset/66684>

[Eric Seidel (no email)]

All reviewed patches have been landed.  Closing bug.