RESOLVED FIXED 80067
Layout Test media/track/track-cues-pause-on-exit.html is flaky on chromium debug builds 
https://bugs.webkit.org/show_bug.cgi?id=80067
Summary Layout Test media/track/track-cues-pause-on-exit.html is flaky on chromium de...
Adam Klein
Reported 2012-03-01 16:29:39 PST
The following layout test is flaky on Chromium debug (all platforms): media/track/track-cues-pause-on-exit.html See: http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=media%2Ftrack%2Ftrack-cues-pause-on-exit.html It seems to have been failing flakily since it was added 9 days ago.
Attachments
Fixed flaky test (3.26 KB, patch)
2012-03-02 06:31 PST, Victor Carbune 		no flags
DetailsFormatted DiffDiff
Corrected coding style issues (3.49 KB, patch)
2012-03-07 15:41 PST, Victor Carbune 		no flags
DetailsFormatted DiffDiff
Patch using waitForEvent (4.79 KB, patch)
2012-04-23 08:15 PDT, Victor Carbune 		no flags
DetailsFormatted DiffDiff
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.
Victor Carbune
Comment 1 2012-03-02 06:31:35 PST
Created attachment 129895 [details] Fixed flaky test This test seems to be flaky because of the to small intervals between cues exit events, which groups them in multiple missed cues at once. The video is paused synchronously while exit events are dispatched asynchronously, which sometimes leads to an inconsistency when the value of video.paused is read
Eric Carlson
Comment 2 2012-03-07 15:07:42 PST
Comment on attachment 129895 [details] Fixed flaky test View in context: https://bugs.webkit.org/attachment.cgi?id=129895&action=review > LayoutTests/media/track/track-cues-pause-on-exit.html:50 > + if (currentCueNumber == 3) { > + endTest(); > + } Nit: braces aren't necessary because there is only one line.
Victor Carbune
Comment 3 2012-03-07 15:41:46 PST
Created attachment 130711 [details] Corrected coding style issues
WebKit Review Bot
Comment 4 2012-03-08 07:51:11 PST
Comment on attachment 130711 [details] Corrected coding style issues Clearing flags on attachment: 130711 Committed r110168: <http://trac.webkit.org/changeset/110168>
WebKit Review Bot
Comment 5 2012-03-08 07:51:16 PST
All reviewed patches have been landed. Closing bug.
Ami Fischman
Comment 6 2012-04-03 17:51:46 PDT
Victor: did you mean to also remove this test from test_expectations.txt? It doesn't seem to be failing anymore.
Eric Carlson
Comment 7 2012-04-04 13:59:37 PDT
It still fails for me, the 'exit' event fires twice for cue ID 0 and ID 1: @@ -16,12 +16,12 @@ EXPECTED (video.paused == 'false') OK EVENT(exit) -EXPECTED (currentCue.id == '2') OK +EXPECTED (currentCue.id == '2'), OBSERVED '0' FAIL EXPECTED (video.paused == 'true') OK RUN(video.play()) EVENT(exit) -EXPECTED (currentCue.id == '3') OK +EXPECTED (currentCue.id == '3'), OBSERVED '1' FAIL EXPECTED (video.paused == 'false') OK END OF TEST
Eric Carlson
Comment 8 2012-04-04 14:23:45 PDT
I wonder if what I am seeing is related to bug #77862?
Victor Carbune
Comment 9 2012-04-23 08:15:54 PDT
Created attachment 138351 [details] Patch using waitForEvent Slightly different approach, waiting for video paused events and after for the queued cue exit events
Eric Carlson
Comment 10 2012-05-04 10:59:56 PDT
Comment on attachment 138351 [details] Patch using waitForEvent Oops, I missed this patch somehow - sorry for the delay in reviewing it!
WebKit Review Bot
Comment 11 2012-05-04 12:53:09 PDT
Comment on attachment 138351 [details] Patch using waitForEvent Clearing flags on attachment: 138351 Committed r116148: <http://trac.webkit.org/changeset/116148>
WebKit Review Bot
Comment 12 2012-05-04 12:53:13 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.