LayoutTest media/controls/pip-placeholder-without-video-controls.html is a flaky failure https://build.webkit.org/results/Apple%20Sierra%20Release%20WK2%20(Tests)/r215094%20(498)/results.html https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=media%2Fcontrols%2Fpip-placeholder-without-video-controls.html --- /Volumes/Data/slave/sierra-release-tests-wk2/build/layout-test-results/media/controls/pip-placeholder-without-video-controls-expected.txt +++ /Volumes/Data/slave/sierra-release-tests-wk2/build/layout-test-results/media/controls/pip-placeholder-without-video-controls-actual.txt @@ -10,7 +10,7 @@ EVENT: webkitpresentationmodechanged PASS: Should be in pip mode PASS: Inline placeholder should be visible at this point -PASS: Inline placeholder should have the 'picture-in-picture' class +FAIL: Inline placeholder should have the 'picture-in-picture' class Expected to contain "picture-in-picture". Actual: "appletv" Testing finished.
This is limited to the Sierra Release WK2 bots according to flakiness dashboard.
(In reply to Ryan Haddad from comment #1) > This is limited to the Sierra Release WK2 bots according to flakiness > dashboard. It looks like the test is also flaky on High Sierra Release WK2, too (though it doesn't fail nearly as often as it does on Sierra).
<rdar://problem/39879021>
Marked test as flaky in https://trac.webkit.org/r231320
On Sierra, I get a reproducible failure with this command: run-webkit-tests --release media/controls/airplay-picker.html media/controls/pip-placeholder-without-video-controls.html --force
The diff definitely points at the media being in AirPlay mode since it has an "appletv" class. So it's a matter of a previous test making this test run in AirPlay still.
Even after setMockMediaPlaybackTargetPickerState(emptyString(), MediaPlaybackTargetContext::Unknown) has been called by Internals::resetToConsistentState() and WebMediaSessionManager::setMockMediaPlaybackTargetPickerState() has received the message from the UI process, which means the state has been reset as expected, the failing test will receive a "webkitcurrentplaybacktargetiswirelesschanged" event and video.webkitCurrentPlaybackTargetIsWireless will be set to true. As such the test thinks it's Airplaying and showing the wrong message.
Even when the test passes, div[pseudo='-webkit-media-controls-wireless-playback-status'].className is "picture-in-picture appletv", which makes no sense to me. It should be one or the other…
The crux of the problem is that HTMLMediaElement::mediaPlayerCurrentPlaybackTargetIsWirelessChanged() is called with the media in the wrong state and this causes the test to act as it's AirPlaying.