It's possible for MediaPlayerPrivateAVFoundationObjC::waitForVideoOutputMediaDataWillChange to be called re-entrantly, if the RunLoop::run() call ends up processing an event that also wants to synchronously update the media image. This can cause a hang: 1. Enter the outer waitForVideoOutputMediaDataWillChange() call. 2. Set up the outer timeout timer. 3. Call RunLoop::run(). 3.1. Enter the inner waitForVideoOutputMediaDataWillChange() call. 3.2. Set up the inner timeout timer. 3.3. Call RunLoop::run(). 3.3.1. Wait for new RunLoop events, and none arrive. 3.3.2. The outer timeout timer fires, calling RunLoop::stop(). 3.4. Return from waitForVideoOutputMediaDataWillChange(), cancelling the inner timeout timer. 3.5. Wait for more events on the run loop, forever. I encountered this with my bug 232565 patch applied running webgl/1.0.x/conformance/textures/misc/texture-corner-case-videos.html.
<rdar://problem/85004449>
(In reply to Cameron McCormack (:heycam) from comment #0) > I encountered this with my bug 232565 patch applied running > webgl/1.0.x/conformance/textures/misc/texture-corner-case-videos.html. bug 230766 rather
Created attachment 443274 [details] Patch
Tools/Scripts/svn-apply failed to apply attachment 443274 [details] to trunk. Please resolve the conflicts and upload a new patch.
Created attachment 443353 [details] Patch for landing
The patch conflicted with bug 232676, which made me realize it was wrong to be modifying m_waitForVideoOutputMediaDataWillChangeTimedOut inside the RunLoop::main() task, since in WebKitLegacy that's the UI thread, and the MediaPlayerPrivateAVFoundationObjC object is created on the web thread. So I've tweaked it to avoid that.
Committed r285330 (243895@main): <https://commits.webkit.org/243895@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 443353 [details].