Bug 163529 – [GTK] Layout test media/video-playback-restriction-play-before-load.html is failing

• Status: RESOLVED
• Resolution: FIXED
• Component: Media

[Michael Catanzaro]

Layout test media/video-playback-restriction-play-before-load.html has been failing since it was added in r201841 "With audio user gesture restriction in place, video.src = 'file', video.play() succeeds where it should fail."  Updating expectations accordingly.

--- /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/media/video-playback-restriction-play-before-load-expected.txt
+++ /home/slave/webkitgtk/gtk-linux-64-release-tests/build/layout-test-results/media/video-playback-restriction-play-before-load-actual.txt
@@ -4,6 +4,6 @@
 RUN(internals.setMediaElementRestrictions(video, "RequireUserGestureForAudioRateChange"))
 RUN(video.src = findMediaFile('video', 'content/test'))
 RUN(video.play().then(resolvePromise, rejectPromise))
-Promise correctly rejected.
+Promise incorrectly resolved. FAIL
 END OF TEST

[Ms2ger (he/him; ⌚ UTC+1/+2)]

What appears to happen here is that we call HTMLMediaElement::setReadyState(), and

m_readyState == HAVE_FUTURE_DATA && oldState <= HAVE_CURRENT_DATA && tracksAreReady

is true, as well as potentiallyPlaying(), so we call scheduleNotifyAboutPlaying(). Only later in the function do we call pauseInternal(), which enqueues a call to rejectPendingPlayPromises().

This means that by the time we try to reject the promise, it's already been resolved. The only obviously related platform-specific code is MediaPlayerPrivateGStreamer::hasAudio(), so I don't know how this would work on mac.

[Philippe Normand]

Fixed in https://trac.webkit.org/r226948

[Radar WebKit Bug Importer]

<rdar://problem/36521997>