[webkit-changes] [WebKit/WebKit] 3a7316: [Cocoa] YouTube videos sometimes do not resize pro...

[aestes]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 3a73162c6129502c6f02cfd71672801267956c05
      https://github.com/WebKit/WebKit/commit/3a73162c6129502c6f02cfd71672801267956c05
  Author: Andy Estes <aestes at apple.com>
  Date:   2023-11-01 (Wed, 01 Nov 2023)

  Changed paths:
    M Source/WebCore/platform/cocoa/VideoPresentationModelVideoElement.mm
    M Source/WebCore/platform/cocoa/WebAVPlayerLayer.mm
    M Source/WebKit/UIProcess/Cocoa/VideoPresentationManagerProxy.mm
    M Source/WebKit/WebProcess/cocoa/VideoPresentationManager.h
    M Source/WebKit/WebProcess/cocoa/VideoPresentationManager.messages.in
    M Source/WebKit/WebProcess/cocoa/VideoPresentationManager.mm

  Log Message:
  -----------
  [Cocoa] YouTube videos sometimes do not resize properly in fullscreen
https://bugs.webkit.org/show_bug.cgi?id=263889
rdar://114570133

Reviewed by Jer Noble.

When a MediaPlayer's metadata becomes available its video dimensions (a.k.a. natural size) are
cached in VideoPresentationModels stored in maps in the WebContent and UI processs, keyed off of the
media element's identifier. This value is used to properly lay out the video's WebAVPlayerLayer.

When a media element needs a compositing layer during layout, a VideoElementData struct is
constructed that stores the current video dimensions. Later, when the newly-created layer is
committed, these dimensions are cached in the UI process' VideoPresentationModel and passed to the
newly-created WebAVPlayerLayer.

Sometimes, committing a layer tree transaction destroys then creates a compositing layer for the
same video element. When the old layer is destroyed, the element's VideoPresentationModel is also
removed from the UI process' map. Then, when the new layer is created, a new VideoPresentationModel
is created with video dimensions from the VideoElementData.

Since layer tree transactions are committed asynchronously after the VideoElementData is
constructed, this creates a race. If video metadata happens to become available after the
VideoElementData was constructed during layout but before the layer tree transaction is committed,
and the transaction involves both destroying and creating the video layer, then the
VideoPresentationModel containing the up-to-date video dimensions will be removed and replaced by a
stale value computed before video metadata became available. This results in the WebAVPlayerLayer
laying out with a false understanding of the video's dimensions (often thinking it is 0x0).

To address this, added a new VideoPresentationManager::EnsureUpdatedVideoDimensions message that is
sent after the UI process creates the new WebAVPlayerLayer. If the video dimensions known to the UI
process no longer match VideoPresentationManager's current dimensions for the element, a new
VideoPresentationManagerProxy::SetVideoDimensions message is sent to the UI process.

* Source/WebCore/platform/cocoa/VideoPresentationModelVideoElement.mm:
(WebCore::VideoPresentationModelVideoElement::setVideoDimensions):
* Source/WebCore/platform/cocoa/WebAVPlayerLayer.mm:
(-[WebAVPlayerLayer setPresentationModel:]):
(-[WebAVPlayerLayer setVideoDimensions:]):
* Source/WebKit/UIProcess/Cocoa/VideoPresentationManagerProxy.mm:
(WebKit::VideoPresentationModelContext::setVideoDimensions):
(WebKit::VideoPresentationManagerProxy::createLayerWithID):
(WebKit::VideoPresentationManagerProxy::createViewWithID):
* Source/WebKit/WebProcess/cocoa/VideoPresentationManager.h:
* Source/WebKit/WebProcess/cocoa/VideoPresentationManager.messages.in:
* Source/WebKit/WebProcess/cocoa/VideoPresentationManager.mm:
(WebKit::VideoPresentationManager::ensureUpdatedVideoDimensions):

Canonical link: https://commits.webkit.org/270061@main