[webkit-changes] [WebKit/WebKit] 62c5bb: Cherry-pick 267399 at main (3e47e6d0c366). https://bu...

Fri Sep 8 01:03:34 PDT 2023

  Branch: refs/heads/webkitglib/2.42
  Home:   https://github.com/WebKit/WebKit
  Commit: 62c5bb27a938b55f679c503293fa0a0bc6058581
      https://github.com/WebKit/WebKit/commit/62c5bb27a938b55f679c503293fa0a0bc6058581
  Author: Carlos Garcia Campos <cgarcia at igalia.com>
  Date:   2023-09-08 (Fri, 08 Sep 2023)

  Changed paths:
    M Source/WebKit/UIProcess/CoordinatedGraphics/DrawingAreaProxyCoordinatedGraphics.cpp
    M Source/WebKit/UIProcess/CoordinatedGraphics/DrawingAreaProxyCoordinatedGraphics.h
    M Source/WebKit/UIProcess/DrawingAreaProxy.messages.in
    M Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.cpp
    M Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.h
    M Source/WebKit/WebProcess/WebPage/DrawingArea.h
    M Source/WebKit/WebProcess/WebPage/DrawingArea.messages.in

  Log Message:
  -----------
  Cherry-pick 267399 at main (3e47e6d0c366). https://bugs.webkit.org/show_bug.cgi?id=259647

    REGRESSION(263118 at main): [CoordinatedGraphics] Incomplete rendering after 10s inactivity without hardware acceleration
    https://bugs.webkit.org/show_bug.cgi?id=260505

    Reviewed by Michael Catanzaro.

    When the backing store is discarded in the UI process we need to notify
    the web process to reset the dirty region to the entire web view and
    ensure next update is not partial. This avoids flickering and ensures a
    full update of the view when a new backing store is created. We should
    also avoid flickering when forcing an update, by waiting for the Update
    message synchronously.

    * Source/WebKit/UIProcess/CoordinatedGraphics/DrawingAreaProxyCoordinatedGraphics.cpp:
    (WebKit::DrawingAreaProxyCoordinatedGraphics::paint):
    (WebKit::DrawingAreaProxyCoordinatedGraphics::forceUpdateIfNeeded):
    (WebKit::DrawingAreaProxyCoordinatedGraphics::incorporateUpdate):
    (WebKit::DrawingAreaProxyCoordinatedGraphics::enterAcceleratedCompositingMode):
    (WebKit::DrawingAreaProxyCoordinatedGraphics::discardBackingStore):
    * Source/WebKit/UIProcess/CoordinatedGraphics/DrawingAreaProxyCoordinatedGraphics.h:
    * Source/WebKit/UIProcess/DrawingAreaProxy.messages.in:
    * Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.cpp:
    (WebKit::DrawingAreaCoordinatedGraphics::updateGeometry):
    (WebKit::DrawingAreaCoordinatedGraphics::didDiscardBackingStore):
    * Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.h:
    * Source/WebKit/WebProcess/WebPage/DrawingArea.h:
    (WebKit::DrawingArea::didDiscardBackingStore):
    * Source/WebKit/WebProcess/WebPage/DrawingArea.messages.in:

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


  Commit: 22fa146615f05821dcbad98a80837f1cc54b77fa
      https://github.com/WebKit/WebKit/commit/22fa146615f05821dcbad98a80837f1cc54b77fa
  Author: Carlos Garcia Campos <cgarcia at igalia.com>
  Date:   2023-09-08 (Fri, 08 Sep 2023)

  Changed paths:
    M Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.cpp
    M Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.h
    M Source/WebKit/WebProcess/WebPage/DrawingArea.h
    M Source/WebKit/WebProcess/WebPage/WebPage.cpp
    M Source/WebKit/WebProcess/WebPage/wc/DrawingAreaWC.h

  Log Message:
  -----------
  Cherry-pick 267733 at main (44051cb8e33a). https://bugs.webkit.org/show_bug.cgi?id=261273

    REGRESSION(262812 at main): No render updates after cross origin history navigation
    https://bugs.webkit.org/show_bug.cgi?id=261273

    Reviewed by Michael Catanzaro.

    This regressed in 262812 at main because we moved the code to enter AC mode
    when always compositing to the DrawingArea constructor to make sure the
    UI process starts receiving IPC messages for the new drawing area as
    soon as possible after a drawing area switch due to cross origin
    navigation. The problem now is when going back after a cross origin
    navigation because there's a display refresh monitor switch too, but to
    create the proper display refresh monitor we need an already created
    drawing area, since WebChromeClient::displayRefreshMonitorFactory()
    returns the WebPage drawing area, not yet set during its constructor.
    So, we need to enter AC mode right after the drawing area is created
    instead of in the constructor to ensure the right display refresh
    monitor is created. This doesn't fail in GTK3 because we create a
    DisplayRefreshMonitorGtk, but that's not the right one either, since
    it's expected to be used only for non-AC mode.

    * Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.cpp:
    (WebKit::DrawingAreaCoordinatedGraphics::DrawingAreaCoordinatedGraphics):
    (WebKit::DrawingAreaCoordinatedGraphics::enterAcceleratedCompositingModeIfNeeded):
    * Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/DrawingAreaCoordinatedGraphics.h:
    * Source/WebKit/WebProcess/WebPage/DrawingArea.h:
    * Source/WebKit/WebProcess/WebPage/WebPage.cpp:
    (WebKit::m_appHighlightsVisible):
    (WebKit::WebPage::reinitializeWebPage):
    * Source/WebKit/WebProcess/WebPage/wc/DrawingAreaWC.h:

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


  Commit: 56f0f3882de8cede7ae22385938c1f0c7edebf3f
      https://github.com/WebKit/WebKit/commit/56f0f3882de8cede7ae22385938c1f0c7edebf3f
  Author: Philippe Normand <philn at igalia.com>
  Date:   2023-09-08 (Fri, 08 Sep 2023)

  Changed paths:
    M Source/WebCore/platform/graphics/gstreamer/ImageGStreamer.h
    M Source/WebCore/platform/graphics/gstreamer/ImageGStreamerCairo.cpp
    M Source/WebCore/platform/graphics/gstreamer/VideoDecoderGStreamer.cpp

  Log Message:
  -----------
  Cherry-pick 267132 at main (dfa421425d51). https://bugs.webkit.org/show_bug.cgi?id=260423

    [GStreamer][WebCodecs] Circular references in video decoder leading to memory leaks
    https://bugs.webkit.org/show_bug.cgi?id=260423

    Reviewed by Xabier Rodriguez-Calvar.

    Circular references between the GStreamerInternalVideoDecoder and its harness through captured
    references in lambdas was preventing proper cleanup of the harness when closing the decoder. Using
    WeakPtrs instead of strong Refs in captured variables fixes the issue.

    Also, driving-by, fixing the ImageGStreamer API to fit with our style guidelines and making sure the
    sample is cleared *after* the associated video frame is un-mapped.

    * Source/WebCore/platform/graphics/gstreamer/ImageGStreamer.h:
    (WebCore::ImageGStreamer::createImage):
    * Source/WebCore/platform/graphics/gstreamer/ImageGStreamerCairo.cpp:
    (WebCore::ImageGStreamer::~ImageGStreamer):
    * Source/WebCore/platform/graphics/gstreamer/VideoDecoderGStreamer.cpp:
    (WebCore::GStreamerInternalVideoDecoder::harnessedElement const):
    (WebCore::GStreamerVideoDecoder::create):
    (WebCore::GStreamerVideoDecoder::~GStreamerVideoDecoder):
    (WebCore::GStreamerInternalVideoDecoder::GStreamerInternalVideoDecoder):
    (WebCore::GStreamerInternalVideoDecoder::decode):

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


  Commit: 02d362b73707c6caa4fb92cceb883d198b4f7304
      https://github.com/WebKit/WebKit/commit/02d362b73707c6caa4fb92cceb883d198b4f7304
  Author: Enrique Ocaña González <eocanha at igalia.com>
  Date:   2023-09-08 (Fri, 08 Sep 2023)

  Changed paths:
    M Source/WebCore/platform/graphics/gstreamer/mse/WebKitMediaSourceGStreamer.cpp

  Log Message:
  -----------
  Cherry-pick 267276 at main (5023d703877c). https://bugs.webkit.org/show_bug.cgi?id=260067

    [MSE][GStreamer] Deadlock while flushing on paused when there's a non in-place transform element
    https://bugs.webkit.org/show_bug.cgi?id=260067

    Reviewed by Alicia Boya Garcia.

    There is a deadlock possible inside WebKit media src (MSE) between streaming thread handling
    CAPS event and pipeline flush in the main thread. This happens in case where there is a
    transform element in the pipeline that does transition NOT in place. Basetransform elem
    expects that it will allocate buffers so on CAPS change it triggers allocation negotiations
    (ALLOCATION query). In such case CAPS event becomes fully synchronous as basetransform does
    ALLOCATION query that is synchronous (serialized with data) and may block the streaming
    thread. If the pipeline is paused and the sink thread doesn't accept any data, this will
    block CAPS event until pipeline is unpaused or flushed. But flush requires a lock that
    streaming thread is holding (DataMutexLocker streamingMembers {
    stream->streamingMembersDataMutex };)

    See: https://github.com/WebPlatformForEmbedded/WPEWebKit/issues/1135

    A way to fix this is to make webKitMediaSrcLoop() release the lock before pushing the caps
    event (which may take a long time to get processed) to let the main thread start the flush.
    Such a flush would cause the sink element to release the streaming thread and the caps event
    processing to finish. After the caps event has been pushed, the lock would be retaken. But
    streamingMembers might have changed under our feet (and it certainly will, because of the
    flush). We should reevaluate if the flush condition is present, and in that case abort the
    execution of webKitMediaSrcLoop() after having paused the streaming task of the
    corresponding pad.

    * Source/WebCore/platform/graphics/gstreamer/mse/WebKitMediaSourceGStreamer.cpp:
    (webKitMediaSrcLoop): Run the caps pushing code with the lock released and reevaluate the flush condition after the lock is reacquired.

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


  Commit: 8f58a5833296d21aff427088a0789aaafc36bcb0
      https://github.com/WebKit/WebKit/commit/8f58a5833296d21aff427088a0789aaafc36bcb0
  Author: Philippe Normand <philn at igalia.com>
  Date:   2023-09-08 (Fri, 08 Sep 2023)

  Changed paths:
    A LayoutTests/http/wpt/mediarecorder/MediaRecorder-start-stop-crash.html
    M Source/WebCore/platform/graphics/gstreamer/GRefPtrGStreamer.cpp
    M Source/WebCore/platform/graphics/gstreamer/GRefPtrGStreamer.h
    M Source/WebCore/platform/mediarecorder/MediaRecorderPrivateGStreamer.cpp
    M Source/WebCore/platform/mediarecorder/MediaRecorderPrivateGStreamer.h

  Log Message:
  -----------
  Cherry-pick 267345 at main (37bc74274076). https://bugs.webkit.org/show_bug.cgi?id=260649

    [GStreamer] Prevent a crash when fetching data on stopped MediaRecorder
    https://bugs.webkit.org/show_bug.cgi?id=260649
    rdar://problem/114370120

    Reviewed by Xabier Rodriguez-Calvar.

    The backend (GStreamer transcoder) is now clearly separated from the MediaRecorderPrivate, so that
    fetchData() can create a weak pointer to be used from the main thread. If the backend was destroyed
    in-flight no unsafe memory access is performed.

    Test: http/wpt/mediarecorder/MediaRecorder-start-stop-crash.html
    Canonical link: https://commits.webkit.org/267345@main


  Commit: 4de1c4bdd98d1550f4374e77a0fb1f7aa608a21f
      https://github.com/WebKit/WebKit/commit/4de1c4bdd98d1550f4374e77a0fb1f7aa608a21f
  Author: Philippe Normand <philn at igalia.com>
  Date:   2023-09-08 (Fri, 08 Sep 2023)

  Changed paths:
    M Source/WebCore/platform/graphics/gstreamer/VideoFrameGStreamer.cpp

  Log Message:
  -----------
  Cherry-pick 267347 at main (0b71df88d472). https://bugs.webkit.org/show_bug.cgi?id=260713

    [GStreamer] VideoFrame metadata not explicitely updated in underlying sample
    https://bugs.webkit.org/show_bug.cgi?id=260713

    Reviewed by Xabier Rodriguez-Calvar.

    Update the sample in case its buffer received additional metadata.

    * Source/WebCore/platform/graphics/gstreamer/VideoFrameGStreamer.cpp:
    (WebCore::VideoFrameGStreamer::VideoFrameGStreamer):

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


  Commit: 8f9cb073220025ea7de436dc3bbeb86817a97c44
      https://github.com/WebKit/WebKit/commit/8f9cb073220025ea7de436dc3bbeb86817a97c44
  Author: Philippe Normand <philn at igalia.com>
  Date:   2023-09-08 (Fri, 08 Sep 2023)

  Changed paths:
    M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp

  Log Message:
  -----------
  Cherry-pick 267663 at main (9c3e31205a2d). https://bugs.webkit.org/show_bug.cgi?id=261144

    [GStreamer] Missing check on mapped video frame validity before pushing to compositor
    https://bugs.webkit.org/show_bug.cgi?id=261144

    Reviewed by Xabier Rodriguez-Calvar.

    Exit early from the pushDMABufToCompositor() method if we failed to map the video frame. No need for
    a dedicated warning, there is one already in gst_video_frame_map().

    * Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
    (WebCore::MediaPlayerPrivateGStreamer::pushDMABufToCompositor):

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


Compare: https://github.com/WebKit/WebKit/compare/d3d4dad6e880...8f9cb0732200