editing/pasteboard/4641033.html timed out on Tiger Bot This is the first time I've noticed this timeout: http://build.webkit.org/results/Tiger%20Intel%20Release/r52905%20(7498)/results.html This test has been here forever: http://trac.webkit.org/browser/trunk/LayoutTests/editing/pasteboard/4641033.html
This seems to be one of the more common tiger failures. I've seen in a couple times this week, including just now: http://build.webkit.org/results/Tiger%20Intel%20Release/r53059%20(7616)/results.html
This still times out every 5 to 10 builds or so on Tiger: http://build.webkit.org/results/Tiger%20Intel%20Release/r53142%20(7670)/results.html If we don't have any theories, we should just skip this test. I get the impression that Tiger support is slowly being deprecated anyway.
I see no reason why this test should be failing unless copy or paste is hanging or unless the DRT timeout machinery is somehow broken on tiger.
I think this test could be re-written to use onload (I think it's trying to wait for the img to load) and possibly be dumpAsText. I might try that.
Created attachment 46697 [details] Patch
I also wonder if the extra </select> close tag could be related to the failure here. I think the selection might unintentionally end up including the <script> tag and we might be copy/pasting the script tag. Not sure.
Comment on attachment 46697 [details] Patch I'm not sure if setTimeout is unnecessary - the original bug was about DOM traversal and presence or renderers, and the DOM is different when still parsing. If this isn't going to fix the problem, better not make arbitrary changes. One possible reason for the test to time out would be an exception being raised. Maybe you could add a try/catch block instead, and log the exception?
Exceptions would show up in the stderr. So I don't think exceptions are involved here. Do we have any idea what this test is actually supposed to be about? It's not at all clear from the test.
I think if we don't understand the test, we should consider skipping it on Tiger, or removing it from the repository in total. :)
Did we get to see stderr? All I see is "file not found".
Created attachment 47074 [details] Patch
run-webkit-tests often makes a stderr link even though there is no stderr file. At least that's my understanding. It's a bug we should fix some day.
Another timeout: http://build.webkit.org/results/Tiger%20Intel%20Release/r53789%20(8117)/results.html
Comment on attachment 47074 [details] Patch ok.
Comment on attachment 47074 [details] Patch Rejecting patch 47074 from commit-queue. Failed to run "['/Users/eseidel/Projects/CommitQueue/WebKitTools/Scripts/svn-apply', '--reviewer', 'Dimitri Glazkov', '--force']" exit_code: 1 patching file LayoutTests/ChangeLog Hunk #1 succeeded at 1 with fuzz 3. patching file LayoutTests/platform/mac-tiger/Skipped Hunk #1 FAILED at 98. 1 out of 1 hunk FAILED -- saving rejects to file LayoutTests/platform/mac-tiger/Skipped.rej Full output: http://webkit-commit-queue.appspot.com/results/283139
Attachment 47074 [details] was posted by a committer and has review+, assigning to Eric Seidel for commit.
Committed r55038: <http://trac.webkit.org/changeset/55038>