Another class of layout tests with bad setTimeouts in them -
Tests of the form:
body onload=runTest();
img
...
function runTest() {
// Wait for img to load
setTimeout(step2, 200);
}
These tests are not flaky, but the setTimeouts are completely
unnecessary (body onload always fires AFTER the
On Tue, Oct 13, 2009 at 3:55 PM, Ojan Vafai o...@chromium.org wrote:
On Tue, Oct 13, 2009 at 3:50 PM, Andrew Scherkus scher...@chromium.orgwrote:
What's happening is loadstart fires and the video reloads which should
cause an abort event. For some reason load will occasionally fire after
This might only apply to the media layout tests, but I'll give the heads up
anyway...
We found flakiness even when using load if the test is explicitly trying to
test for stalled/progress/abort events before the load is completed:
On Tue, Oct 13, 2009 at 3:50 PM, Andrew Scherkus scher...@chromium.orgwrote:
What's happening is loadstart fires and the video reloads which should
cause an abort event. For some reason load will occasionally fire after
loadstart, ending the test.
I know we can patch the test, but I've been
YAY! :) Begone ye setTimeout!
setTimeout is also lame because it makes the tests run slower.
-eric
On Fri, Oct 9, 2009 at 9:52 PM, Julie Parent jpar...@chromium.org wrote:
For those of you looking into flaky tests -
I've found a surprising number of tests that are flaky because they use a
Most awesome. Very good catch.
On Fri, Oct 9, 2009 at 9:52 PM, Julie Parent jpar...@chromium.org wrote:
For those of you looking into flaky tests -
I've found a surprising number of tests that are flaky because they use a
setTimeout to guarantee that a resource (usually an iframe) has
