174241 2017-07-06 22:31:54 -0700 [GTK] Layout test media/video-inactive-playback.html is timing out 2018-01-15 07:32:56 -0800 1 1 1 Unclassified WebKit WebKitGTK Other PC Linux RESOLVED FIXED P2 Normal --- 162582 1 mcatanzaro webkit-unassigned ap bugs-noreply cturner eric.carlson jer.noble mcatanzaro Ms2ger pnormand oldest_to_newest 1326393 0 mcatanzaro 2017-07-06 22:31:54 -0700 Layout test media/video-inactive-playback.html is timing out on the GTK port since it was added in r218417 "[iOS] Do not pause playing video when application resigns active state." Updating expectations accordingly. 1335916 1 Ms2ger 2017-08-07 03:59:59 -0700 I looked into this and the problem is that the test sets restrictions on the "videoaudio" session: run('internals.setMediaSessionRestrictions("videoaudio", "")'); run('internals.setMediaSessionRestrictions("videoaudio", "inactiveprocessplaybackrestricted")'); while forEachSession only finds a "video" session. This means nothing special happens and neither the expected "pause" or the expected "playing" event are fired. (However, a "playing" event is fired as the result of the video finishing naturally.) It's not clear to me why this test works at all on other platforms. Jer, thoughts? 1335963 2 jer.noble 2017-08-07 08:57:46 -0700 (In reply to Ms2ger from comment #1) > I looked into this and the problem is that the test sets restrictions on the > "videoaudio" session: > > run('internals.setMediaSessionRestrictions("videoaudio", "")'); > run('internals.setMediaSessionRestrictions("videoaudio", > "inactiveprocessplaybackrestricted")'); > > while forEachSession only finds a "video" session. This means nothing > special happens and neither the expected "pause" or the expected "playing" > event are fired. > > (However, a "playing" event is fired as the result of the video finishing > naturally.) > > It's not clear to me why this test works at all on other platforms. > > Jer, thoughts? The file LayoutTests/media/content/test.{mp4,ogv} should have both an audio and a video track, so the resulting session should be of MediaType "VideoAudio", and not just "Video". It sounds like that's the source of your problem. If you look at HTMLMediaElement::mediaType(), it will return VideoAudio if the readyState >= HAVE_METADATA, the MediaPlayerPrivate return true for hasVideo() & hasAudio(), and the element is not muted. So either this test is being run before the "loadedmetadata" event is fired, or the GTK media player doesn't think the file has audio. 1337340 3 Ms2ger 2017-08-10 00:47:43 -0700 The problem appears to be that Page::m_mutedState is AudioIsMuted. I have not yet been able to figure out how it got that way. 1337414 4 Ms2ger 2017-08-10 07:59:11 -0700 Looks like this and a bunch of other tests were broken by bug 162582. 1337445 5 jer.noble 2017-08-10 09:07:56 -0700 (In reply to Ms2ger from comment #4) > Looks like this and a bunch of other tests were broken by bug 162582. Sounds like the GTK media player is reporting !hasAudio() when the page state is muted. That seems wrong. 1337479 6 mcatanzaro 2017-08-10 10:25:40 -0700 (In reply to Jer Noble from comment #5) > (In reply to Ms2ger from comment #4) > > Looks like this and a bunch of other tests were broken by bug 162582. > > Sounds like the GTK media player is reporting !hasAudio() when the page > state is muted. That seems wrong. Charlie, this would be a good one for you or Calvaris to look into. 1337842 7 Ms2ger 2017-08-10 23:44:51 -0700 The code isn't specific to GTK, though: bool HTMLMediaElement::effectiveMuted() const { return muted() || (document().page() && document().page()->isAudioMuted()); } 1388176 8 pnormand 2018-01-11 02:22:36 -0800 Ms2ger was right in comment 3, the page is muted by default by WKTR so the test should un-mute it in its go function with internals.setPageMuted(""); I'm also a bit confused as to why this passes on other platforms, I'll try to dig this down further... 1388187 9 pnormand 2018-01-11 03:20:16 -0800 The current explanation I have is that in the player the volume element gets muted based on MediaPlayer::muted() value, which is true because the page is muted. I think this behavior is different on other platforms, so that's why they don't need to explicitely un-mute the page. 1388188 10 pnormand 2018-01-11 03:32:19 -0800 Another potential issue is that hasAudio() might return false before the gst pipeline is fully built and the audio track was discovered. This effectively short-cuts the page state too... 1389270 11 pnormand 2018-01-15 03:15:55 -0800 On mac the test passes because the AVF player doesn't support muting, so the volume is set to 0 from the player POV in HTMLMediaElement::updatePlayState() but the HTMLMediaElement m_muted attribute remains false. This is an inconsistency :( Moreover the AVF player ::setMuted() method is implemented for both mac and iOS but supportsMuting() returns true only for iOS, yet another inconsistency. If I replace the m_player->setMuted() call with a setMuted() call in HTMLMediaElement::updatePlayState() I get the test timeout on mac, same as in GTK. 1389296 12 pnormand 2018-01-15 07:32:56 -0800 Fixed in https://trac.webkit.org/r226948 But maybe the Apple folks should consider checking the little inconsistencies I found in the AVF player?