http/tests/media/video-play-stall-seek.html http/tests/media/video-play-stall.html http/tests/media/video-seekable-stall.html --- /tmp/layout-test-results/http/tests/media/video-play-stall-seek-expected.txt 2010-02-22 16:19:37.000000000 -0800 +++ /tmp/layout-test-results/http/tests/media/video-play-stall-seek-actual.txt 2010-02-22 16:19:37.000000000 -0800 @@ -1,11 +1,5 @@ +FAIL: Timed out waiting for notifyDone to be called Test that playback can be resumed by seeking backwards after load stalls. RUN(video.play()) -EVENT(waiting) -EXPECTED (video.readyState == '2') OK -RUN(video.currentTime = 0.1) -EVENT(canplay) -EXPECTED (video.readyState >= '2') OK -EXPECTED (video.networkState == '2') OK -END OF TEST --- /tmp/layout-test-results/http/tests/media/video-play-stall-expected.txt 2010-02-22 16:19:53.000000000 -0800 +++ /tmp/layout-test-results/http/tests/media/video-play-stall-actual.txt 2010-02-22 16:19:53.000000000 -0800 @@ -1,3 +1,4 @@ +FAIL: Timed out waiting for notifyDone to be called Test that stalled, timeupdate and waiting events are sent when media load stalls in the middle. RUN(video.play()) @@ -5,8 +6,6 @@ EVENT(loadedmetadata) EVENT(loadeddata) EVENT(canplay) +EVENT(canplaythrough) EVENT(timeupdate) -EVENT(waiting) -EVENT(stalled) -END OF TEST --- /tmp/layout-test-results/http/tests/media/video-seekable-stall-expected.txt 2010-02-22 16:19:53.000000000 -0800 +++ /tmp/layout-test-results/http/tests/media/video-seekable-stall-actual.txt 2010-02-22 16:19:53.000000000 -0800 @@ -5,7 +5,6 @@ TEST(video.seekable.length == 1) OK TEST(video.seekable.start(0) == 0) OK TEST(video.seekable.end(0) > 0) OK -TEST(video.seekable.end(0) < video.duration - 1) OK -TEST(video.currentTime = video.duration - 1) THROWS(DOMException.INDEX_SIZE_ERR) OK +TEST(video.seekable.end(0) < video.duration - 1) FAIL END OF TEST I'm happy to provide more information about the machine. Perhaps I'm the only one seeing this. I'm not sure when this started.
I'm able to reliably reproduce the http/tests/media/video-seekable-stall.html failure.
I've moved the CQ back to that machine again, so now this is a blocking issue for me. I'll look into skipping the test for just the cq.
I may need to file a new bug. The one remaining failure is this: --- /tmp/layout-test-results/http/tests/media/video-seekable-stall-expected.txt 2010-08-03 15:06:49.000000000 -0700 +++ /tmp/layout-test-results/http/tests/media/video-seekable-stall-actual.txt 2010-08-03 15:06:49.000000000 -0700 @@ -5,6 +5,6 @@ TEST(video.seekable.length == 1) OK TEST(video.seekable.start(0) == 0) OK TEST(video.seekable.end(0) > 0) OK -TEST(video.seekable.end(0) < video.duration - 1) OK +TEST(video.seekable.end(0) < video.duration - 1) FAIL END OF TEST
Committed r64611: <http://trac.webkit.org/changeset/64611>
(Slightly regrettably) I've skipped the test for now on Leopard as the most expedient solution. I'm certain my machine is not the only one seeing this failure.
I'm working on a related bug with video-seekable-stall for chromium and have an issue with the last check in the test: TEST(video.seekable.end(0) < video.duration - 1) OK Why the "-1"? The max time range, "video.seekable.end(0)" is defined to be video.duration plus the time of the first frame in the video (which is zero)... http://www.w3.org/TR/html5/video.html#dom-media-seekable With the "-1" removed, this will work in chromium... (when I've checked in another fix)...
(In reply to comment #6) > I'm working on a related bug with video-seekable-stall for chromium and have an issue with the last check in the test: > > TEST(video.seekable.end(0) < video.duration - 1) OK > > Why the "-1"? The max time range, "video.seekable.end(0)" is defined to be video.duration plus the time of the first frame in the video (which is zero)... > > http://www.w3.org/TR/html5/video.html#dom-media-seekable > > With the "-1" removed, this will work in chromium... (when I've checked in another fix)... The test was written at a time when the only media engine, QuickTime, could only seek to a time that was already loaded so checking that the last range was before "duration - 1" was correct because of the stallAt=100000. This behavior is still true of QuickTime on Windows, so removing the "-1" will make it fail. I think this test has outlived its usefulness
It's currently skipped on windows. I'll send a patch to remove the test.
Created attachment 95503 [details] Patch
I"m OK with this if Eric is.
The commit-queue encountered the following flaky tests while processing attachment 95503 [details]: http/tests/websocket/tests/error-detect.html bug 54012 (author: abarth@webkit.org) The commit-queue is continuing to process your patch.
Comment on attachment 95503 [details] Patch Clearing flags on attachment: 95503 Committed r87817: <http://trac.webkit.org/changeset/87817>
All reviewed patches have been landed. Closing bug.