Bug 60055 – media/video-volume-slider.html causes GTK 64 bit debug bot to time out

• Status: RESOLVED
• Resolution: FIXED
• Component: Tools / Tests

[Mario Sanchez Prada]

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

[Philippe Normand]

It could be the event sender not hiting the correct position in the page

[Philippe Normand]

Created attachment 92563 [details]
proposed patch

[Philippe Normand]

Created attachment 93269 [details]
updated patch

[WebKit Review Bot]

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

[WebKit Review Bot]

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

[Philippe Normand]

(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 :)

[Philippe Normand]

Bug 60693 I mean!

[Martin Robinson]

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.

[Philippe Normand]

Committed r86535: <http://trac.webkit.org/changeset/86535>