Branch: refs/heads/webkitglib/2.52
  Home:   https://github.com/WebKit/WebKit
  Commit: 0e02310d2a2755175ddcb6ae123a7303901e707e
      
https://github.com/WebKit/WebKit/commit/0e02310d2a2755175ddcb6ae123a7303901e707e
  Author: Rodrigo Alencar <[email protected]>
  Date:   2026-05-09 (Sat, 09 May 2026)

  Changed paths:
    M Source/WebCore/loader/FrameLoader.cpp

  Log Message:
  -----------
  Cherry-pick 312779@main (c7cf80229641). 
https://bugs.webkit.org/show_bug.cgi?id=314187

    [Leak] Service worker fetch() retains ResourceResponses in the remote 
worker DocumentLoader
    https://bugs.webkit.org/show_bug.cgi?id=314187

    Reviewed by Youenn Fablet.

    Synthesized documents mark their FrameLoader state as Complete directly
    instead of going through setState(FrameState::Complete). That bypasses the
    normal DocumentLoader::stopRecordingResponses() call.

    Remote worker pages used by service workers are initialized this way. When
    service worker fetches go through their backing document loader,
    each response can be recorded in DocumentLoader::m_responses even though the
    document is already complete. This causes ResourceResponses to be retained 
for
    the lifetime of the remote worker page.

    Call stopRecordingResponses() when initializing synthesized documents so 
their
    DocumentLoader matches the normal Complete state behavior.

    No new automated test because this retention is only visible through native
    WebContent memory inspection. The Web platform cannot observe
    DocumentLoader::m_responses or m_stopRecordingResponses.

    Manual test: ran a local WKWebView service worker fetch harness before and 
after
    this change. Before: the remote worker DocumentLoader retained 5059 
responses
    and had m_stopRecordingResponses=false. After: the remote worker 
DocumentLoader
    retained 0 responses and had m_stopRecordingResponses=true.

    * Source/WebCore/loader/FrameLoader.cpp:
    (WebCore::FrameLoader::initForSynthesizedDocument):

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

Canonical link: https://commits.webkit.org/305877.482@webkitglib/2.52


  Commit: dcae236cd5c5c4b4786331c1e4753c6b6123b44a
      
https://github.com/WebKit/WebKit/commit/dcae236cd5c5c4b4786331c1e4753c6b6123b44a
  Author: Adrian Taylor <[email protected]>
  Date:   2026-05-09 (Sat, 09 May 2026)

  Changed paths:
    M Source/WebCore/platform/graphics/x11/XErrorTrapper.h

  Log Message:
  -----------
  Cherry-pick 312878@main (959829501d2d). 
https://bugs.webkit.org/show_bug.cgi?id=314395

    [Swift GTK] Undefined Success
    https://bugs.webkit.org/show_bug.cgi?id=314395

    Reviewed by Adrian Perez de Castro.

    The X11 header defines Success. This causes difficulty when this header is
    transitively included in some Swift/C++ import scenarios, since the 
definition
    of Success causes problems interpreting the 'Success' case of other enums
    across the codebase. Undefine Success since we don't currently need it.

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

Canonical link: https://commits.webkit.org/305877.483@webkitglib/2.52


  Commit: 02dec333499a21f79a66430f87dd40db698b0930
      
https://github.com/WebKit/WebKit/commit/02dec333499a21f79a66430f87dd40db698b0930
  Author: Claudio Saavedra <[email protected]>
  Date:   2026-05-09 (Sat, 09 May 2026)

  Changed paths:
    M Source/WebCore/platform/text/hyphen/HyphenationLibHyphen.cpp

  Log Message:
  -----------
  Cherry-pick 312894@main (f5ad6e77a2db). 
https://bugs.webkit.org/show_bug.cgi?id=309589

    Crash in WebCore::lastHyphenLocation
    https://bugs.webkit.org/show_bug.cgi?id=309589

    Reviewed by Adrian Perez de Castro.

    Speculative fix. If the dictionary can't be opened for whatever reason, we 
end up
    with a nullptr HyphenDictUniquePtr in HyphenationDictionary. This can be 
due to
    broken symlinks, corrupted files, etc. Guarding this might fix the crash.

    * Source/WebCore/platform/text/hyphen/HyphenationLibHyphen.cpp:
    (WebCore::lastHyphenLocation):

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

Canonical link: https://commits.webkit.org/305877.484@webkitglib/2.52


Compare: https://github.com/WebKit/WebKit/compare/4d68c4bc4669...02dec333499a

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

Reply via email to