The test has been very flaky since many builds ago. On a flaky failure the diff looks like: Source: https://build.webkit.org/results/GTK%20Linux%2064-bit%20Release%20(Tests)/r260030%20(13319)/imported/w3c/web-platform-tests/media-source/mediasource-correct-frames-after-reappend-diff.txt --- /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/imported/w3c/web-platform-tests/media-source/mediasource-correct-frames-after-reappend-expected.txt +++ /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/imported/w3c/web-platform-tests/media-source/mediasource-correct-frames-after-reappend-actual.txt @@ -1,3 +1,7 @@ +CONSOLE MESSAGE: Error: assert_true: The note being played matches the expected one (boxes lit: 1, 466.2 Hz), found ~441.4 Hz expected true got false +CONSOLE MESSAGE: Error: assert_true: The note being played matches the expected one (boxes lit: 2, 493.9 Hz), found ~441.4 Hz expected true got false + +Harness Error (FAIL), message = Error: assert_true: The note being played matches the expected one (boxes lit: 2, 493.9 Hz), found ~441.4 Hz expected true got false PASS Test the expected frames are played at the expected times, even in presence of reappends If the error is not relevant the error message can be skipped with DumpJSConsoleLogInStdErr.