platform/chromium/fast/text/text-stroke-with-border.html has been flaky for quite a while: http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=platform%2Fchromium%2Ffast%2Ftext%2Ftext-stroke-with-border.html&showExpectations=true However, it almost always passes when retried. Looking at the diffs, it's supposed to have a 800x600 layout, but instead it ends up with a 360x240 one, even though it does no resizing. Looking at a test log (http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.6/builds/8553/steps/webkit_tests/logs/stdio), it looks like the worker that runs it also runs platform/chromium/fast/repaint/fixed-layout-360x240.html shortly before. You can also reproduce this locally with: run-webkit-tests --chromium --release --no-retry-failures platform/chromium/fast/repaint/fixed-layout-360x240.html platform/chromium/fast/text/text-stroke-with-border.html (both tests pass when run in insolation) The first test uses LayoutTestController capabilities that were added http://trac.webkit.org/changeset/94779 to switch to fixed layout. However, in between tests we never switch the ScrollView from out of fixed layout mode, so subsequent tests (until the next DRT process restart, which could be 1,000 tests later) end up in this inconsistent state. I'll look into resetting fixed layout mode.
Thanks for catching this. This should be a one-liner in Tools/DumpRenderTree/chromium/LayoutTestController.cpp. LayoutTestController::reset() that sets m_shell->webView()->enableFixedLayoutMode(false); Thanks again.
Created attachment 108879 [details] Patch
Wasn't sure about where to do this resetting (where you mentioned vs. WebViewHost::reset() vs. TestShell::resetTestController()). I ended up going with the latter, since it's where we also reset page scaling, which seems similar.
Committed r96147: <http://trac.webkit.org/changeset/96147>