The following test is a flaky failure on iOS and macOS bots: TestWebKitAPI.GPUProcess.CrashWhilePlayingVideo LEAK: 1 WebProcessPool LEAK: 1 WebPageProxy /Volumes/Data/slave/bigsur-debug/build/Tools/TestWebKitAPI/Tests/WebKitCocoa/GPUProcess.mm:282 Value of: [webView _isPlayingAudio] Actual: false Expected: true https://results.webkit.org/?suite=api-tests&test=TestWebKitAPI.MediaSessionTest.RemoteCommands
<rdar://problem/74220428>
Pasted in the wrong history link. Here is the right one: https://results.webkit.org/?suite=api-tests&test=TestWebKitAPI.GPUProcess.CrashWhilePlayingVideo
It looks like this test has been flaky on iOS for a while, but the macOS flakiness is relatively new (appears to have started with https://trac.webkit.org/changeset/272414/webkit according to test history)
(In reply to Ryan Haddad from comment #3) > It looks like this test has been flaky on iOS for a while Looking more closely, that is known and tracked by https://bugs.webkit.org/show_bug.cgi?id=221499
Dupe of bug 221499?
Sorry, I now see that you said that - but should we dupe?
(In reply to Alexey Proskuryakov from comment #6) > Sorry, I now see that you said that - but should we dupe? The macOS failure is still in need of investigation.
Created attachment 427708 [details] Patch
Committed r277018 (237334@main): <https://commits.webkit.org/237334@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 427708 [details].
Reopening since the test is still flaky.
Created attachment 427803 [details] Patch
Comment on attachment 427803 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=427803&action=review > Tools/ChangeLog:10 > + relying on [webView _isPlayingAudio]. Also use a test page with a single video element instead Does this uncover a potential issue with _isPlayingAudio in case of crash? > Tools/TestWebKitAPI/Tests/WebKitCocoa/GPUProcess.mm:320 > + [webView objectByEvaluatingJavaScriptWithUserGesture:@"document.getElementsByTagName('video')[0].play() && true"]; Why not just doing @"play()"?
(In reply to youenn fablet from comment #12) > Comment on attachment 427803 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=427803&action=review > > > Tools/ChangeLog:10 > > + relying on [webView _isPlayingAudio]. Also use a test page with a single video element instead > > Does this uncover a potential issue with _isPlayingAudio in case of crash? Maybe, we'll see if this speculative fix is successful. > > Tools/TestWebKitAPI/Tests/WebKitCocoa/GPUProcess.mm:320 > > + [webView objectByEvaluatingJavaScriptWithUserGesture:@"document.getElementsByTagName('video')[0].play() && true"]; > > Why not just doing @"play()"? Good point, will update.
Created attachment 427884 [details] Patch
(In reply to Chris Dumez from comment #13) > (In reply to youenn fablet from comment #12) > > Comment on attachment 427803 [details] > > Patch > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=427803&action=review > > > > > Tools/ChangeLog:10 > > > + relying on [webView _isPlayingAudio]. Also use a test page with a single video element instead > > > > Does this uncover a potential issue with _isPlayingAudio in case of crash? > > Maybe, we'll see if this speculative fix is successful. Although I don't think this has anything to do with crash recovery since _isPlayingAudio would refuse to become true *before* the crash on the bots.
Committed r277101 (237403@main): <https://commits.webkit.org/237403@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 427884 [details].
*** Bug 225475 has been marked as a duplicate of this bug. ***
Given the above, do we need a separate bug about [webView _isPlayingAudio] not working reliably? Please file one if we do.
No recent API test failures on macOS, it looks like this was successful.