It was observed that, after revision r85586 [1], the media tests in the 64 bit started to time out always in the same place. After checking the tests_run.txt file [2], it looks like the problem is in this test, so I'm skipping it now to unblock this bot while we don't find a better solution for it. [1] http://trac.webkit.org/changeset/85586 [2] http://build.webkit.org/results/GTK%20Linux%2064-bit%20Debug/r85620%20%2822092%29/tests_run.txt
It could be the event sender not hiting the correct position in the page
Created attachment 92563 [details] proposed patch
Created attachment 93269 [details] updated patch
Comment on attachment 93269 [details] updated patch Attachment 93269 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/8688667 New failing tests: media/video-volume-slider.html
Created attachment 93270 [details] Archive of layout-test-results from ec2-cr-linux-01 The attached test failures were seen while running run-webkit-tests on the chromium-ews. Bot: ec2-cr-linux-01 Port: Chromium Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
(In reply to comment #5) > Created an attachment (id=93270) [details] > Archive of layout-test-results from ec2-cr-linux-01 > > The attached test failures were seen while running run-webkit-tests on the chromium-ews. > Bot: ec2-cr-linux-01 Port: Chromium Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick See bug 60293. Would be nice if the EWS could handle bug dependencies :)
Bug 60693 I mean!
Comment on attachment 93269 [details] updated patch View in context: https://bugs.webkit.org/attachment.cgi?id=93269&action=review > LayoutTests/media/video-volume-slider.html:30 > + x = muteCoords[0]; > + y = muteCoords[1]; > eventSender.mouseMoveTo(x, y); You could just pass the coordinates directly here ala eventSender.moveMouseTo(muteCoords[0], museCoords[1]); without much loss of explication.
Committed r86535: <http://trac.webkit.org/changeset/86535>