Bug 35271

Summary: http/tests/media/video-seekable-stall.html fails on the Leopard Commit Queue Machine
Product: WebKit Reporter: Eric Seidel (no email) <eric>
Component: Tools / TestsAssignee: Steve Lacey <sjl>
Status: RESOLVED FIXED    
Severity: Normal CC: abarth, commit-queue, eric.carlson, scherkus, sjl
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: OS X 10.5   
Attachments:
Description Flags
Patch none

Eric Seidel (no email)
Reported 2010-02-22 16:29:50 PST
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.
Attachments
Patch (8.61 KB, patch)
2011-05-31 16:15 PDT, Steve Lacey 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Eric Seidel (no email)
Comment 1 2010-05-12 10:24:31 PDT
I'm able to reliably reproduce the http/tests/media/video-seekable-stall.html failure.
Eric Seidel (no email)
Comment 2 2010-08-03 15:10:27 PDT
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.
Eric Seidel (no email)
Comment 3 2010-08-03 15:11:15 PDT
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
Eric Seidel (no email)
Comment 4 2010-08-03 18:29:52 PDT
Committed r64611: <http://trac.webkit.org/changeset/64611>
Eric Seidel (no email)
Comment 5 2010-08-03 18:36:22 PDT
(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.
Steve Lacey
Comment 6 2011-05-31 15:44:03 PDT
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)...
Eric Carlson
Comment 7 2011-05-31 15:53:12 PDT
(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
Steve Lacey
Comment 8 2011-05-31 16:02:55 PDT
It's currently skipped on windows. I'll send a patch to remove the test.
Steve Lacey
Comment 9 2011-05-31 16:15:23 PDT
Created attachment 95503 [details] Patch
Eric Seidel (no email)
Comment 10 2011-05-31 18:50:34 PDT
I"m OK with this if Eric is.
WebKit Commit Bot
Comment 11 2011-06-01 09:25:34 PDT
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.
WebKit Commit Bot
Comment 12 2011-06-01 09:27:34 PDT
Comment on attachment 95503 [details] Patch Clearing flags on attachment: 95503 Committed r87817: <http://trac.webkit.org/changeset/87817>
WebKit Commit Bot
Comment 13 2011-06-01 09:27:39 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.