Bug 194916 – fast/mediastream/MediaStream-video-element.html is flaky

• Component: Tools / Tests
• Status: NEW

[Chris Dumez]

fast/mediastream/MediaStream-video-element.html is flaky:
--- /Volumes/Data/slave/highsierra-release-tests-wk2/build/layout-test-results/fast/mediastream/MediaStream-video-element-expected.txt
+++ /Volumes/Data/slave/highsierra-release-tests-wk2/build/layout-test-results/fast/mediastream/MediaStream-video-element-actual.txt
@@ -47,7 +47,7 @@
 video.audioTracks[0] properties:
   track.id = <UUID>
   track.kind = main
-  track.label = Mock audio device 1
+  track.label = 
   track.language = 
   track.enabled = true
   track.sourceBuffer = null

Steps to reproduce:
run-webkit-tests fast/mediastream/MediaStream-video-element-video-tracks-disabled.html fast/mediastream/MediaStream-video-element.html --child-processes 1

[Chris Dumez]

This is somehow related to using a different WebView for the 2 tests but the same WKContext/WebProcessPool. I am not super familiar with this code. I spent some time trying to understand the mock media devices code yesterday but could not figure out the issue.

[Chris Dumez]

This started with https://trac.webkit.org/changeset/241821 which avoids re-constructing a new WKContext / WebProcessPool between tests whenever possible.

[Radar WebKit Bug Importer]

<rdar://problem/48345402>

[Truitt Savell]

Marked test as failing to get the tree green while waiting on resolution:
https://trac.webkit.org/changeset/242044/webkit

[Chris Dumez]

You can reproduce it with the test by itself:
Tools/Scripts/run-webkit-tests fast/mediastream/MediaStream-video-element.html -gf --repeat-each=50

So it is a flaky test and r241821 merely impacted the timing of things, making the test flakier.

[Chris Dumez]

The test is relying on a setTimeout(100):

function canplay()
{
    debug("<br>*** start playback ****");
    evalAndLog("video.play()");
    setTimeout(checkVideoElement, 100);
}

:/

[Ryosuke Niwa]

This test appears to be always failing now?÷