Branch: refs/heads/webkitglib/2.50
  Home:   https://github.com/WebKit/WebKit
  Commit: f57e9fded5b868e44a872e3039b43c835c4526f6
      
https://github.com/WebKit/WebKit/commit/f57e9fded5b868e44a872e3039b43c835c4526f6
  Author: Pascoe <[email protected]>
  Date:   2026-01-07 (Wed, 07 Jan 2026)

  Changed paths:
    M Source/WebKit/NetworkProcess/NetworkProcess.cpp
    M Source/WebKit/NetworkProcess/NetworkProcessCreationParameters.h
    M 
Source/WebKit/NetworkProcess/NetworkProcessCreationParameters.serialization.in
    M Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp
    M Source/WebKit/UIProcess/Network/NetworkProcessProxy.h
    M Source/WebKit/UIProcess/WebPageProxy.cpp

  Log Message:
  -----------
  Cherry-pick 305173@main (99d7f658ab04). 
https://bugs.webkit.org/show_bug.cgi?id=301321

    Potential crash under WebPageProxy::executeEditCommand()
    rdar://145887512
    https://bugs.webkit.org/show_bug.cgi?id=301321

    Reviewed by Charlie Wolfe.

    Hardening fix to avoid calling protectedConnection() when the NetworkProcess
    doesn't have an established connection yet. Also add hasRunningProcess() 
check
    in the callback version's completion handler.

    Additionally, track pending file paths that need to be allowed in
    NetworkProcessProxy (similar to allowedFirstPartiesForCookies) and send them
    via NetworkProcessCreationParameters when the NetworkProcess launches. This
    ensures file access is properly granted even if NetworkProcess crashes and
    restarts.

    This fix is somewhat speculative as I couldn't reproduce the crash in 
testing.

    * Source/WebKit/NetworkProcess/NetworkProcess.cpp:
    (WebKit::NetworkProcess::initializeNetworkProcess):
    * Source/WebKit/NetworkProcess/NetworkProcessCreationParameters.h:
    * 
Source/WebKit/NetworkProcess/NetworkProcessCreationParameters.serialization.in:
    * Source/WebKit/UIProcess/Cocoa/WebPasteboardProxyCocoa.mm:
    (WebKit::WebPasteboardProxy::grantAccessToCurrentData):
    * Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp:
    (WebKit::NetworkProcessProxy::sendCreationParametersToNewProcess):
    (WebKit::NetworkProcessProxy::networkProcessDidTerminate):
    (WebKit::NetworkProcessProxy::addPendingAllowedFilePaths):
    * Source/WebKit/UIProcess/Network/NetworkProcessProxy.h:
    * Source/WebKit/UIProcess/WebPageProxy.cpp:
    (WebKit::WebPageProxy::executeEditCommand):

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

Canonical link: https://commits.webkit.org/298234.374@webkitglib/2.50


  Commit: 0badfff108bc272852662c4dc880cadf8df9465d
      
https://github.com/WebKit/WebKit/commit/0badfff108bc272852662c4dc880cadf8df9465d
  Author: Ryosuke Niwa <[email protected]>
  Date:   2026-01-07 (Wed, 07 Jan 2026)

  Changed paths:
    M Source/WebCore/dom/EventListenerMap.h

  Log Message:
  -----------
  Cherry-pick 305171@main (7dc2a5e431ad). 
https://bugs.webkit.org/show_bug.cgi?id=304961

    Occasional release assert failure in 
EventListenerMap::clearEntriesForTearDown
    https://bugs.webkit.org/show_bug.cgi?id=304961
    <rdar://166613518>

    Reviewed by Chris Dumez.

    When a GC thread sweeps an event target, the release assertion in
    releaseAssertOrSetThreadUID() could fail as the thread ID will not match.

    Allow a GC thread to tear down EventTarget used in another thread.

    No new tests since we don't have a reliable reproduction.

    * Source/WebCore/dom/EventListenerMap.h:
    (WebCore::EventListenerMap::releaseAssertOrSetThreadUID):

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

Canonical link: https://commits.webkit.org/298234.375@webkitglib/2.50


  Commit: 19953373b6891b922295edbf8699718bad288408
      
https://github.com/WebKit/WebKit/commit/19953373b6891b922295edbf8699718bad288408
  Author: Youenn Fablet <[email protected]>
  Date:   2026-01-07 (Wed, 07 Jan 2026)

  Changed paths:
    M 
Source/ThirdParty/libwebrtc/Source/third_party/libvpx/source/libvpx/vp8/common/mfqe.c

  Log Message:
  -----------
  Cherry-pick 305148@main (7fc39a64c04a). 
https://bugs.webkit.org/show_bug.cgi?id=304935

    Use-of-uninitialized-value in vp8_multiframe_quality_enhance
    rdar://166234834
    https://bugs.webkit.org/show_bug.cgi?id=304935

    Reviewed by Eric Carlson.

    We cherry-pick 
https://chromium.googlesource.com/webm/libvpx/+/70a4f20f9931d7128dfa5ebe0bef5c3021a435c3%5E%21.
    Covered by existing tests.

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

Canonical link: https://commits.webkit.org/298234.376@webkitglib/2.50


  Commit: 4ccaa454e71906dd9fb106fd5976fc173fdf028f
      
https://github.com/WebKit/WebKit/commit/4ccaa454e71906dd9fb106fd5976fc173fdf028f
  Author: Nathan Solomon <[email protected]>
  Date:   2026-01-12 (Mon, 12 Jan 2026)

  Changed paths:
    A 
LayoutTests/compositing/filters/filter-region-translated-child-expected.html
    A LayoutTests/compositing/filters/filter-region-translated-child.html
    M Source/WebCore/rendering/RenderBox.cpp
    M Source/WebCore/rendering/RenderBox.h

  Log Message:
  -----------
  Cherry-pick 305393@main (0cb4b26572e4). 
https://bugs.webkit.org/show_bug.cgi?id=305032

    REGRESSION (296844@main): filter region fails to cover transformed children 
of the filtered element
    https://bugs.webkit.org/show_bug.cgi?id=305032
    rdar://167671935

    Reviewed by Simon Fraser.

    If a parent element has a filter applied and contains a child element
    with transforms or relative positioning, the filter region calculated
    by the parent may not include the child's transformed position. If the
    filter region is not included, then this causes incorrect visual
    results where the filter is only applied onto the parent but not the
    child (ex: a gaussian blur is only on the parent element but not on
    the child element).

    Fix this by modifying addOverflowWithRendererOffset() to include
    children with self-painting layers in the parent's visual overflow
    calculation when the parent has a filter. Previously, we assumed that
    if a child has its own painting layer, the parent does not need to
    track the child's visual overflow. However, this assumption is
    incorrect when the parent has a filter, because the filter effect
    requires accurate bounds that include all visual children regardless
    of their layer status.

    Additionally, fix visualOverflowRectForPropagation() to correctly
    compute the visual overflow rectangle when the child element has CSS
    transforms or relative positioning. The overflow rectangle must be
    converted from the child's local coordinate space to the parent's
    coordinate space.

    Test: compositing/filters/filter-region-translated-child.html

    * 
LayoutTests/compositing/filters/filter-region-translated-child-expected.html: 
Added.
    * LayoutTests/compositing/filters/filter-region-translated-child.html: 
Added.
    * Source/WebCore/rendering/RenderBox.cpp:
    (WebCore::RenderBox::addOverflowWithRendererOffset):
    (WebCore::RenderBox::applyPaintGeometryTransformToRect const):
    (WebCore::RenderBox::convertRectToParentWritingMode const):
    (WebCore::RenderBox::visualOverflowRectForPropagation const):
    (WebCore::RenderBox::layoutOverflowRectForPropagation const):
    * Source/WebCore/rendering/RenderBox.h:

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

Canonical link: https://commits.webkit.org/298234.377@webkitglib/2.50


Compare: https://github.com/WebKit/WebKit/compare/7b69bb42b477...4ccaa454e719

To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications

Reply via email to