[webkit-changes] [WebKit/WebKit] 6c0572: Cherry-pick 272313 at main (64a739754a58). https://bu...

[Michael Catanzaro]

  Branch: refs/heads/webkitglib/2.42
  Home:   https://github.com/WebKit/WebKit
  Commit: 6c0572949bd248174e407c0c6880c72e5a98e56b
      https://github.com/WebKit/WebKit/commit/6c0572949bd248174e407c0c6880c72e5a98e56b
  Author: Sihui Liu <sihui_liu at apple.com>
  Date:   2024-01-27 (Sat, 27 Jan 2024)

  Changed paths:
    M Source/WebKit/NetworkProcess/storage/NetworkStorageManager.cpp

  Log Message:
  -----------
  Cherry-pick 272313 at main (64a739754a58). https://bugs.webkit.org/show_bug.cgi?id=266603

    Ensure NetworkStorageManager gets destroyed on the main thread
    https://bugs.webkit.org/show_bug.cgi?id=266603
    rdar://117839300

    Reviewed by Chris Dumez and Alex Christensen.

    Dispatch a task to main thread to release ref of NetworkStorageManager in stopReceivingMessageFromConnection, which may
    help fix the crash under IDBStorageRegistry::removeConnectionToClient in rdar://117839300.

    * Source/WebKit/NetworkProcess/storage/NetworkStorageManager.cpp:
    (WebKit::NetworkStorageManager::stopReceivingMessageFromConnection):

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


  Commit: b989c958c8561c6f4de8dc2cb352eddafe23c120
      https://github.com/WebKit/WebKit/commit/b989c958c8561c6f4de8dc2cb352eddafe23c120
  Author: Ahmad Saleem <ahmad.saleem792+github at gmail.com>
  Date:   2024-01-27 (Sat, 27 Jan 2024)

  Changed paths:
    M Source/WebCore/Modules/webdatabase/SQLTransactionCoordinator.cpp

  Log Message:
  -----------
  Cherry-pick 272316 at main (4a40fea04d2f). https://bugs.webkit.org/show_bug.cgi?id=266552

    Fix hang in SQLTransactionCoordinator::shutdown()

    https://bugs.webkit.org/show_bug.cgi?id=266552

    Reviewed by Chris Dumez.

    Merge: https://src.chromium.org/viewvc/blink?view=revision&revision=181269

    We should call `takeFirst` instead of `first` to decrease the size of
    `info.pendingTransactions`.

    Also update 'RefPtr<SQLTransaction>' to 'RefPtr'.

    This changes does not have any test case.

    * Source/WebCore/Modules/webdatabase/SQLTransactionCoordinator.cpp:
    (SQLTransactionCoordinator::shutdown):

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


  Commit: 15fe369994edffef24fb29d2fc4c5c71528206a9
      https://github.com/WebKit/WebKit/commit/15fe369994edffef24fb29d2fc4c5c71528206a9
  Author: Vitaly Dyachkov <vitaly at igalia.com>
  Date:   2024-01-27 (Sat, 27 Jan 2024)

  Changed paths:
    M Source/WebCore/page/WheelEventTestMonitor.cpp
    M Source/WebCore/page/WheelEventTestMonitor.h

  Log Message:
  -----------
  Cherry-pick 272356 at main (e9a0efd9166f). https://bugs.webkit.org/show_bug.cgi?id=266624

    [WPE] ASSERTION FAILED: m_thread.ptr() == &Thread::current()
    https://bugs.webkit.org/show_bug.cgi?id=266624

    Reviewed by Chris Dumez.

    When threaded scrolling is used, we may end up execuring
    `WheelEventTestMonitor::scheduleCallbackCheck()` in the scrolling
    thread.

    Then when trying to create `WeakRef` of the `Page` we hit the assertion
    in Debug builds because the `Page` can only make single thread weak ptr.

    To solve this, this patch makes `WheelEventTestMonitor` be able to make
    thread-safe weak ptr and then accesses the page using its `m_page`
    instance variable.

    * LayoutTests/platform/wpe/TestExpectations:
    * Source/WebCore/page/WheelEventTestMonitor.cpp:
    (WebCore::WheelEventTestMonitor::scheduleCallbackCheck):
    * Source/WebCore/page/WheelEventTestMonitor.h:

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


  Commit: 67f4a4118be3bec081f23fc9f5364adca9b662b1
      https://github.com/WebKit/WebKit/commit/67f4a4118be3bec081f23fc9f5364adca9b662b1
  Author: Enrique Ocaña González <eocanha at igalia.com>
  Date:   2024-01-28 (Sun, 28 Jan 2024)

  Changed paths:
    M Source/WebCore/platform/AbortableTaskQueue.h
    M Source/WebCore/platform/graphics/gstreamer/TrackPrivateBaseGStreamer.cpp

  Log Message:
  -----------
  Cherry-pick 272410 at main (b1393655168b). https://bugs.webkit.org/show_bug.cgi?id=266715

    [GStreamer] Fix delayed dispatch of async task post MediaPlayer destruction
    https://bugs.webkit.org/show_bug.cgi?id=266715

    Reviewed by Xabier Rodriguez-Calvar.

    When the media player is destroyed, there can still be async tasks (from AbortableTaskQueue)
    ongoing, some of them related to tracks. Those tasks should be aborted, because they depend
    on objects that are no longer there.

    This patch aborts all pending tasks on AbortableTaskQueue destruction and also unregisters
    all pending callbacks from TrackPrivateBaseGStreamer (and asserts that they're no longer
    there).

    See: https://github.com/WebPlatformForEmbedded/WPEWebKit/pull/1231

    Original author: "Vivek.A" <Vivek_Arumugam at comcast.com>

    * Source/WebCore/platform/AbortableTaskQueue.h: Abort tasks on destruction.
    * Source/WebCore/platform/graphics/gstreamer/TrackPrivateBaseGStreamer.cpp:
    (WebCore::TrackPrivateBaseGStreamer::disconnect): Disconnect handlers and assert.

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


  Commit: 67e712ae194d695fd8b9b9ef4ee97c6575bae785
      https://github.com/WebKit/WebKit/commit/67e712ae194d695fd8b9b9ef4ee97c6575bae785
  Author: Rose <83477269+AtariDreams at users.noreply.github.com>
  Date:   2024-01-28 (Sun, 28 Jan 2024)

  Changed paths:
    M Source/WebKit/Platform/IPC/StreamClientConnectionBuffer.h
    M Source/WebKit/Platform/IPC/StreamServerConnectionBuffer.h

  Log Message:
  -----------
  Cherry-pick 272461 at main (d2ba4a07e209). https://bugs.webkit.org/show_bug.cgi?id=266649

    Fix the failure memory order argument to compareExchangeStrong
    https://bugs.webkit.org/show_bug.cgi?id=266649

    Reviewed by Kimmo Kinnunen.

    The failure memory order cannot be release or acq_rel.
    Clang since llvm/llvm-project at fed5644 diagnoses an invalid argument.
    Furthermore, the current way it is written is undefined behavior anyway.

    From https://en.cppreference.com/w/cpp/atomic/atomic/compare_exchange:
    "If failure is stronger than success or(until C++17) is one of
    std::memory_order_release and std::memory_order_acq_rel, the behavior is
    undefined."

    * Source/WebKit/Platform/IPC/StreamClientConnectionBuffer.h:
      (IPC::StreamClientConnectionBuffer::tryAcquire): Use
      memory_order_acquire as fallback.
    * Source/WebKit/Platform/IPC/StreamServerConnectionBuffer.h:
      (IPC::StreamServerConnectionBuffer::tryAcquire): Ditto.

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


  Commit: 80ed64c31d22f2a73adf42f4810ead01ed260778
      https://github.com/WebKit/WebKit/commit/80ed64c31d22f2a73adf42f4810ead01ed260778
  Author: Simon Fraser <simon.fraser at apple.com>
  Date:   2024-01-28 (Sun, 28 Jan 2024)

  Changed paths:
    M Source/WebCore/rendering/RenderLayerCompositor.cpp

  Log Message:
  -----------
  Cherry-pick 272588 at main (a2e00ce3745e). https://bugs.webkit.org/show_bug.cgi?id=267002

    Null check the ScrollingCoordinator in a few places
    https://bugs.webkit.org/show_bug.cgi?id=267002
    rdar://116427384

    Reviewed by Alan Baradlay.

    We dereference the return value of RenderLayerCompositor::scrollingCoordinator() in
    a couple of places without null-checking, so fix that.

    * Source/WebCore/rendering/RenderLayerCompositor.cpp:
    (WebCore::RenderLayerCompositor::attachScrollingNode):
    (WebCore::RenderLayerCompositor::detachScrollCoordinatedLayer):

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


  Commit: fbca3a62ab6b3fa669a63456c97695f2bf1d84f8
      https://github.com/WebKit/WebKit/commit/fbca3a62ab6b3fa669a63456c97695f2bf1d84f8
  Author: Olivier Blin <olivier.blin at softathome.com>
  Date:   2024-01-28 (Sun, 28 Jan 2024)

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

  Log Message:
  -----------
  Cherry-pick 272605 at main (087cd6903b83). https://bugs.webkit.org/show_bug.cgi?id=266758

    [MSE][GStreamer] Fix releasing Stream and GstStream objects
    https://bugs.webkit.org/show_bug.cgi?id=266758

    Reviewed by Philippe Normand.

    There was a circular reference between WebKitMediaSrcPadPrivate which
    owns a RefPtr<Stream>, and Stream which owns a GRefPtr<GstPad> const pad.

    * Source/WebCore/platform/graphics/gstreamer/mse/WebKitMediaSourceGStreamer.cpp:
    (webKitMediaSrcTearDownStream):

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


  Commit: 55a3958cb3895aa9c491f3a8cbbfe8aeb0128192
      https://github.com/WebKit/WebKit/commit/55a3958cb3895aa9c491f3a8cbbfe8aeb0128192
  Author: Justin Michaud <justin_michaud at apple.com>
  Date:   2024-01-28 (Sun, 28 Jan 2024)

  Changed paths:
    A JSTests/stress/gc-b3.js
    M Source/JavaScriptCore/bytecode/CodeBlock.cpp
    M Source/JavaScriptCore/dfg/DFGPlan.cpp

  Log Message:
  -----------
  Cherry-pick 272710 at main (cae26b36ccb9). https://bugs.webkit.org/show_bug.cgi?id=267112

    GC can run during B3::generate now, causing UAF in patchpoints
    https://bugs.webkit.org/show_bug.cgi?id=267112
    rdar://120195529

    Reviewed by Yusuke Suzuki.

    Consider what happens when GC runs here:
    {
        SetForScope disallowFreeze { state.graph.m_frozenValuesAreFinalized, true };
        GraphSafepoint safepoint(state.graph, safepointResult);

        // HERE

        B3::generate(*state.proc, jit);
    }

    We can see our global object and a bunch of plan state get collected.

    Inside FTLLowerDFGToB3, we read the following pointers:

    ```
    jit.codeBlock()->globalObjectFor(semanticNodeOrigin)
    codeBlock()->inferredName() / hash(), which read ownerExecutable()
    state->jitCode
    ``

    The first case is fixed by this patch. The second case only happens when
    dumping code. The third is not managed by the GC.

    It is possible that we read more, but these were the cases that jumped out
    to me.

    We just add an early return to globalObjectFor to avoid reading the
    freed value.

    * Source/JavaScriptCore/bytecode/CodeBlock.cpp:
    (JSC::CodeBlock::globalObjectFor):
    * Source/JavaScriptCore/dfg/DFGPlan.cpp:
    (JSC::DFG::Plan::cancel):
    * Source/JavaScriptCore/ftl/FTLCompile.cpp:
    (JSC::FTL::compile):

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


  Commit: e34a30337ac419fb25b9024a60177e25bae12f15
      https://github.com/WebKit/WebKit/commit/e34a30337ac419fb25b9024a60177e25bae12f15
  Author: Philippe Normand <philn at igalia.com>
  Date:   2024-01-29 (Mon, 29 Jan 2024)

  Changed paths:
    M Source/WebCore/platform/audio/gstreamer/WebKitWebAudioSourceGStreamer.cpp

  Log Message:
  -----------
  Cherry-pick 268584 at main (fe502bf25fce). https://bugs.webkit.org/show_bug.cgi?id=262183

    [GStreamer][WebAudio] Misc cleanups
    https://bugs.webkit.org/show_bug.cgi?id=262183

    Reviewed by Xabier Rodriguez-Calvar.

    The source pad caps don't change, so we can build and store the GstAudioInfo once instead of for
    every push iteration. webKitWebAudioSrcAllocateBuffers was also renamed to
    webKitWebAudioSrcAllocateBuffer for consistency.

    * Source/WebCore/platform/audio/gstreamer/WebKitWebAudioSourceGStreamer.cpp:
    (webKitWebAudioSrcConstructed):
    (webKitWebAudioSrcAllocateBuffer):
    (webKitWebAudioSrcRenderIteration):
    (webKitWebAudioSrcAllocateBuffers): Deleted.

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


  Commit: 89cad368080cf90486e42f36436c701723e68dad
      https://github.com/WebKit/WebKit/commit/89cad368080cf90486e42f36436c701723e68dad
  Author: Philippe Normand <philn at igalia.com>
  Date:   2024-01-29 (Mon, 29 Jan 2024)

  Changed paths:
    M LayoutTests/platform/glib/TestExpectations
    M Source/WebCore/platform/audio/gstreamer/AudioDestinationGStreamer.cpp
    M Source/WebCore/platform/audio/gstreamer/WebKitWebAudioSourceGStreamer.cpp
    M Source/WebCore/platform/audio/gstreamer/WebKitWebAudioSourceGStreamer.h

  Log Message:
  -----------
  Cherry-pick 272761 at main (1fdb9251bb08). https://bugs.webkit.org/show_bug.cgi?id=264934

    [GStreamer] imported/w3c/web-platform-tests/webaudio/the-audio-api/the-audioworklet-interface/audioworklet-registerprocessor-called-on-globalthis.https is flaky crash
    https://bugs.webkit.org/show_bug.cgi?id=264934

    Reviewed by Xabier Rodriguez-Calvar.

    Store the AudioBus as a RefPtr in the GStreamer weaudiosrc element. Using a raw pointer provided no
    guarantee the underlying data was still valid.

    * LayoutTests/platform/glib/TestExpectations:
    * Source/WebCore/platform/audio/gstreamer/AudioDestinationGStreamer.cpp:
    (WebCore::AudioDestinationGStreamer::AudioDestinationGStreamer):
    * Source/WebCore/platform/audio/gstreamer/WebKitWebAudioSourceGStreamer.cpp:
    (webkit_web_audio_src_class_init):
    (webKitWebAudioSrcConstructed):
    (webKitWebAudioSrcSetProperty):
    (webKitWebAudioSrcGetProperty):
    (webKitWebAudioSrcRenderAndPushFrames):
    (webkitWebAudioSourceSetBus):
    * Source/WebCore/platform/audio/gstreamer/WebKitWebAudioSourceGStreamer.h:

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


  Commit: a1796de50381821b7493752a78e84f67299359f4
      https://github.com/WebKit/WebKit/commit/a1796de50381821b7493752a78e84f67299359f4
  Author: Philippe Normand <philn at igalia.com>
  Date:   2024-01-29 (Mon, 29 Jan 2024)

  Changed paths:
    M Source/WebCore/platform/mediastream/gstreamer/GStreamerMediaStreamSource.cpp

  Log Message:
  -----------
  Cherry-pick 272777 at main (ef04947b5537). https://bugs.webkit.org/show_bug.cgi?id=267127

    [GStreamer][MediaStream] Track removal doesn't trigger corresponding appsrc removal
    https://bugs.webkit.org/show_bug.cgi?id=267127

    Reviewed by Xabier Rodriguez-Calvar.

    Clean-up the corresponding appsrc and pad when a MediaStreamTrack is removed from its MediaStream.

    * Source/WebCore/platform/mediastream/gstreamer/GStreamerMediaStreamSource.cpp:
    (WebKitMediaStreamObserver::didRemoveTrack):

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


  Commit: 6386848b0f623926379363570da7dd52d11424f3
      https://github.com/WebKit/WebKit/commit/6386848b0f623926379363570da7dd52d11424f3
  Author: Philippe Normand <philn at igalia.com>
  Date:   2024-01-29 (Mon, 29 Jan 2024)

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

  Log Message:
  -----------
  Cherry-pick 272778 at main (4792e094b47d). https://bugs.webkit.org/show_bug.cgi?id=132262

    [GLIB] http/tests/media/video-redirect.html is flaky timing out and crashing on Wayland
    https://bugs.webkit.org/show_bug.cgi?id=132262

    Reviewed by Xabier Rodriguez-Calvar.

    Address the crash, EmptyOriginAccessPatterns::singleton() expects a non-WebProcess, which is not the
    case, so use originAccessPatternsForWebProcessOrEmpty() which is more appropriate.

    * LayoutTests/platform/glib/TestExpectations:
    * Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
    (WebCore::MediaPlayerPrivateGStreamer::loadNextLocation):

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


  Commit: f47952e22520e4010c8c77eb3800d106cee33191
      https://github.com/WebKit/WebKit/commit/f47952e22520e4010c8c77eb3800d106cee33191
  Author: Loïc Yhuel <loic.yhuel at softathome.com>
  Date:   2024-01-29 (Mon, 29 Jan 2024)

  Changed paths:
    M Source/WebCore/platform/mediastream/gstreamer/GStreamerCaptureDeviceManager.cpp

  Log Message:
  -----------
  Cherry-pick 272804 at main (0af0ad4fe5bf). https://bugs.webkit.org/show_bug.cgi?id=267234

    [GStreamer][MediaStream] Do not initialize on teardown
    https://bugs.webkit.org/show_bug.cgi?id=267234

    Reviewed by Philippe Normand.

    The capture device managers were created on exit, including possibly a full GStreamer init.

    * Source/WebCore/platform/mediastream/gstreamer/GStreamerCaptureDeviceManager.cpp:
    (WebCore::GStreamerAudioCaptureDeviceManager::singleton):
    (WebCore::GStreamerVideoCaptureDeviceManager::singleton):
    (WebCore::teardownGStreamerCaptureDeviceManagers):

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


  Commit: 69ad89f7e72431e98a6db565669409327d84456a
      https://github.com/WebKit/WebKit/commit/69ad89f7e72431e98a6db565669409327d84456a
  Author: Philippe Normand <philn at igalia.com>
  Date:   2024-01-29 (Mon, 29 Jan 2024)

  Changed paths:
    M Source/WTF/wtf/PlatformGTK.cmake
    M Source/WTF/wtf/PlatformWPE.cmake
    A Source/WTF/wtf/glib/GThreadSafeWeakPtr.h
    M Source/WebCore/platform/graphics/gstreamer/WebKitWebSourceGStreamer.cpp
    M Tools/TestWebKitAPI/Tests/WTF/glib/GWeakPtr.cpp

  Log Message:
  -----------
  Cherry-pick 272807 at main (6a9d7a164705). https://bugs.webkit.org/show_bug.cgi?id=266973

    [GStreamer] Crash in CachedResourceStreamingClient::dataReceived
    https://bugs.webkit.org/show_bug.cgi?id=266973

    Reviewed by Michael Catanzaro, Carlos Garcia Campos and Xabier Rodriguez-Calvar.

    Store the WebKitWebSrc pointer as a weak reference in the CachedResourceStreamingClient. Using a
    const raw pointer was not sufficient, because nothing prevented other code to dispose the element,
    thus making the pointer point to garbage. We can't use a strong reference because it would introduce
    a reference cycle between WebKitWebSrc and the CachedResourceStreamingClient.

    * Source/WebCore/platform/graphics/gstreamer/WebKitWebSourceGStreamer.cpp:
    (webKitWebSrcMakeRequest):
    (CachedResourceStreamingClient::CachedResourceStreamingClient):
    (CachedResourceStreamingClient::~CachedResourceStreamingClient):
    (CachedResourceStreamingClient::checkUpdateBlocksize):
    (CachedResourceStreamingClient::responseReceived):
    (CachedResourceStreamingClient::dataReceived):
    (CachedResourceStreamingClient::accessControlCheckFailed):
    (CachedResourceStreamingClient::loadFailed):
    (CachedResourceStreamingClient::loadFinished):

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


  Commit: a23f51344acf868f6d37d12178c516585a8dc054
      https://github.com/WebKit/WebKit/commit/a23f51344acf868f6d37d12178c516585a8dc054
  Author: Antti Koivisto <antti at apple.com>
  Date:   2024-01-29 (Mon, 29 Jan 2024)

  Changed paths:
    A LayoutTests/fast/ruby/ruby-frameset-display-none-crash-expected.txt
    A LayoutTests/fast/ruby/ruby-frameset-display-none-crash.html
    M Source/WebCore/html/HTMLFrameElement.cpp
    M Source/WebCore/html/HTMLFrameSetElement.cpp
    M Source/WebCore/html/HTMLFrameSetElement.h
    M Source/WebCore/style/StyleAdjuster.cpp

  Log Message:
  -----------
  Cherry-pick 272846 at main (8395281e9b92). https://bugs.webkit.org/show_bug.cgi?id=267331

    [iFC][Ruby] frameset with display:none crashes in ruby
    https://bugs.webkit.org/show_bug.cgi?id=267331
    rdar://120496400

    Reviewed by Alan Baradlay.

    <frameset> generates a renderer even with 'display:none' breaking some assumptions.

    * LayoutTests/fast/ruby/ruby-frameset-display-none-crash-expected.txt: Added.
    * LayoutTests/fast/ruby/ruby-frameset-display-none-crash.html: Added.
    * Source/WebCore/html/HTMLFrameElement.cpp:
    (WebCore::HTMLFrameElement::rendererIsNeeded):
    * Source/WebCore/html/HTMLFrameSetElement.cpp:
    (WebCore::HTMLFrameSetElement::rendererIsNeeded): Deleted.
    * Source/WebCore/html/HTMLFrameSetElement.h:
    * Source/WebCore/style/StyleAdjuster.cpp:
    (WebCore::Style::Adjuster::adjust const):

    Adjust frameset/frame always have 'display:block', even when it is orginally 'none'.
    This matches other browsers.

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


  Commit: 6a781d4dc0dcac50887aea7944cf5b781d76e5b0
      https://github.com/WebKit/WebKit/commit/6a781d4dc0dcac50887aea7944cf5b781d76e5b0
  Author: Philippe Normand <philn at igalia.com>
  Date:   2024-01-29 (Mon, 29 Jan 2024)

  Changed paths:
    M Source/WebCore/Modules/mediastream/gstreamer/GStreamerMediaEndpoint.cpp

  Log Message:
  -----------
  Cherry-pick 272909 at main (62752b330f81). https://bugs.webkit.org/show_bug.cgi?id=267328

    [GStreamer][WebRTC] WPT test RTCPeerConnection-restartIce.https.html is crashing
    https://bugs.webkit.org/show_bug.cgi?id=267328

    Reviewed by Xabier Rodriguez-Calvar.

    Exit early from restartIce() in case there is no pipeline, addressing the crash. Also remove the
    code triggering a new offer, that's not going to be sufficient, and is actually triggering ASSERTs
    in Debug builds.
    * Source/WebCore/Modules/mediastream/gstreamer/GStreamerMediaEndpoint.cpp:
    (WebCore::GStreamerMediaEndpoint::restartIce):

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


  Commit: f5b4e00ce0c1f66f4372da6cd7043bda359b3251
      https://github.com/WebKit/WebKit/commit/f5b4e00ce0c1f66f4372da6cd7043bda359b3251
  Author: Philippe Normand <philn at igalia.com>
  Date:   2024-01-29 (Mon, 29 Jan 2024)

  Changed paths:
    M Source/WebCore/Modules/mediastream/gstreamer/GStreamerMediaEndpoint.cpp

  Log Message:
  -----------
  Cherry-pick 272910 at main (2404f7bae653). https://bugs.webkit.org/show_bug.cgi?id=267327

    [GStreamer][WebRTC] WPT test RTCPeerConnection-setLocalDescription-offer.html is crashing
    https://bugs.webkit.org/show_bug.cgi?id=267327

    Reviewed by Xabier Rodriguez-Calvar.

    Check the SDP message contains enough medias before attempting to access the one located at the
    given mline index.

    * Source/WebCore/Modules/mediastream/gstreamer/GStreamerMediaEndpoint.cpp:
    (WebCore::GStreamerMediaEndpoint::onIceCandidate):

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


  Commit: 23229297c752120602962ab294f5534ce08488ec
      https://github.com/WebKit/WebKit/commit/23229297c752120602962ab294f5534ce08488ec
  Author: Charlie Wolfe <charliew at apple.com>
  Date:   2024-01-29 (Mon, 29 Jan 2024)

  Changed paths:
    M Source/WebKit/NetworkProcess/storage/NetworkStorageManager.cpp
    M Source/WebKit/NetworkProcess/storage/NetworkStorageManager.h

  Log Message:
  -----------
  Cherry-pick 272951 at main (cc8a261932c7). https://bugs.webkit.org/show_bug.cgi?id=266559

    Safari periodically erasing LocalStorage and IndexedDB for all websites
    https://bugs.webkit.org/show_bug.cgi?id=266559
    rdar://119818267

    Reviewed by Sihui Liu.

    Data eviction will delete website data for all origins if the total disk usage exceeds the total quota.
    `m_totalQuota` is set in `NetworkStorageManager::spaceGrantedForOrigin()`, and will only be set if
    `m_totalQuota` is zero. However, `m_totalQuota` is never initialized, so it's possible for it to have a
    non-zero value which is less than the current disk usage. This situation prevents the variable from ever
    being initialized in `NetworkStorageManager::spaceGrantedForOrigin()` and results in the deletion of all
    website data.

    This change addresses the issue by making `m_totalQuota` optional, ensuring the value is always null when
    `NetworkStorageManager::spaceGrantedForOrigin()` is initially called.

    * Source/WebKit/NetworkProcess/storage/NetworkStorageManager.cpp:
    (WebKit::NetworkStorageManager::spaceGrantedForOrigin):
    (WebKit::NetworkStorageManager::performEviction):
    * Source/WebKit/NetworkProcess/storage/NetworkStorageManager.h:

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


  Commit: e6fa099e55782fbed44b95d0bf3993ffca56fbaf
      https://github.com/WebKit/WebKit/commit/e6fa099e55782fbed44b95d0bf3993ffca56fbaf
  Author: Vitaly Dyachkov <vitaly at igalia.com>
  Date:   2024-01-29 (Mon, 29 Jan 2024)

  Changed paths:
    M Source/WebCore/Modules/notifications/NotificationResourcesLoader.cpp
    M Source/WebCore/Modules/notifications/NotificationResourcesLoader.h

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

    [GTK][WPE][Debug] imported/w3c/web-platform-tests/notifications/instance.https.html is a constant crash
    https://bugs.webkit.org/show_bug.cgi?id=267132

    Reviewed by Carlos Garcia Campos.

    Currently, when `NotificationResourcesLoader` starts downloading
    notification resources, we create a "ResourceLoader" per resource
    (we only support the icon resource for now) and add it to the set of
    running loaders `m_loaders`.

    When a `ResourceLoader` finishes, we check if it was the last one
    running. If yes, we run the `NotificationResourcesLoader`'s completion
    handler.

    But in some circumstances (e.g. when the icon URL is bogus)
    a `ResouceLoader` can execute its completion handler synchronously
    during construction.

    In this case, the `NotificationResourcesLoader`'s completion handler
    will be called from `didFinishLoadingResource()` because
    `m_loaders.isEmpty()` since we haven't added the loader to the set yet.

    To prevent it, this patch checks that `ResouceLoader` hasn't finished
    yet before adding it to the set of running loaders.

    * Source/WebCore/Modules/notifications/NotificationResourcesLoader.cpp:
    (WebCore::NotificationResourcesLoader::start):
    (WebCore::NotificationResourcesLoader::stop):
    (WebCore::NotificationResourcesLoader::didFinishLoadingResource):
    (WebCore::NotificationResourcesLoader::ResourceLoader::didFinishLoading):
    (WebCore::NotificationResourcesLoader::ResourceLoader::didFail):
    * Source/WebCore/Modules/notifications/NotificationResourcesLoader.h:

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


  Commit: d88076f2fd9e81d8ba23a8c0451f6aa537e154a5
      https://github.com/WebKit/WebKit/commit/d88076f2fd9e81d8ba23a8c0451f6aa537e154a5
  Author: Yusuke Suzuki <ysuzuki at apple.com>
  Date:   2024-01-29 (Mon, 29 Jan 2024)

  Changed paths:
    M Source/JavaScriptCore/llint/LowLevelInterpreter.cpp

  Log Message:
  -----------
  Cherry-pick 273318 at main (c1f8a9e81920). https://bugs.webkit.org/show_bug.cgi?id=267881

    Unreviewed, build fix for CLoop
    https://bugs.webkit.org/show_bug.cgi?id=267881
    rdar://121391447

    * Source/JavaScriptCore/llint/LowLevelInterpreter.cpp:
    (JSC::CLoop::execute):

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


  Commit: c72d9688bab6379928cd9bcb272070aef5cffcca
      https://github.com/WebKit/WebKit/commit/c72d9688bab6379928cd9bcb272070aef5cffcca
  Author: Philippe Normand <philn at igalia.com>
  Date:   2024-01-29 (Mon, 29 Jan 2024)

  Changed paths:
    M Source/WebCore/platform/mediastream/gstreamer/GStreamerVideoCapturer.cpp

  Log Message:
  -----------
  Cherry-pick 273491 at main (7725039edc39). https://bugs.webkit.org/show_bug.cgi?id=268003

    [GStreamer][MediaStream] http/wpt/mediastream/transfer-mediastreamtrack-to-worker.html asserts/fails
    https://bugs.webkit.org/show_bug.cgi?id=268003

    Reviewed by Xabier Rodriguez-Calvar.

    The test was failing/asserting because the notified video frames were created with a zero
    presentation size. By using the createWrappedSample() API the presentation size is set from the
    sample caps.

    * LayoutTests/platform/glib/TestExpectations:
    * Source/WebCore/platform/mediastream/gstreamer/GStreamerVideoCapturer.cpp:
    (WebCore::GStreamerVideoCapturer::setSinkVideoFrameCallback):

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


  Commit: 47b473ce14d6c50f3836d6b02380f75a78e1c113
      https://github.com/WebKit/WebKit/commit/47b473ce14d6c50f3836d6b02380f75a78e1c113
  Author: Karl Dubost <karlcow at apple.com>
  Date:   2024-01-29 (Mon, 29 Jan 2024)

  Changed paths:
    M Source/WebCore/page/Quirks.cpp

  Log Message:
  -----------
  Cherry-pick 273567 at main (803558a9d300). https://bugs.webkit.org/show_bug.cgi?id=268130

    365scores.com: Quirks needed to silence the resize events when putting Safari in the background (iPadOS)
    https://bugs.webkit.org/show_bug.cgi?id=268130
    rdar://116491386

    Reviewed by Brent Fulgham.

    When setting the 365scores.com in the background/foreground on iPad,
    some resize events are being fired. These events in return modifies
    the layout when it should stay the same. This patch add this domain
    to the existing quirk to solve this type of issues.

    * Source/WebCore/page/Quirks.cpp:
    (WebCore::Quirks::shouldSilenceWindowResizeEvents const):

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


  Commit: 1d37ed0cf1ac9e65058e6d13dcc798bdb5a8f54f
      https://github.com/WebKit/WebKit/commit/1d37ed0cf1ac9e65058e6d13dcc798bdb5a8f54f
  Author: Michael Catanzaro <mcatanzaro at redhat.com>
  Date:   2024-02-02 (Fri, 02 Feb 2024)

  Changed paths:
    M Source/WebCore/platform/graphics/gtk/GdkCairoUtilities.cpp
    M Source/WebKit/UIProcess/API/glib/WebKitFaviconDatabase.cpp
    M Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp

  Log Message:
  -----------
  Cherry-pick 273907 at main (39559cbd2d25). https://bugs.webkit.org/show_bug.cgi?id=252435

    [GTK] gdk_memory_texture_new: assertion 'width > 0' failed in cairoSurfaceToGdkTexture
    https://bugs.webkit.org/show_bug.cgi?id=252435

    Reviewed by Carlos Garcia Campos.

    If the cairo surface does not have positive width and height, we need to
    not attempt to create a GdkTexture, and return a valid error.

    * Source/WebCore/platform/graphics/gtk/GdkCairoUtilities.cpp:
    (WebCore::cairoSurfaceToGdkTexture):
    * Source/WebKit/UIProcess/API/glib/WebKitFaviconDatabase.cpp:
    (webkit_favicon_database_get_favicon_finish):
    * Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp:

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


Compare: https://github.com/WebKit/WebKit/compare/9d55c4dceb7e...1d37ed0cf1ac