Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: 591ea9f65ca1c679f48423cf4dadb69be2806326
https://github.com/WebKit/WebKit/commit/591ea9f65ca1c679f48423cf4dadb69be2806326
Author: Geoffrey Garen <[email protected]>
Date: 2026-05-21 (Thu, 21 May 2026)
Changed paths:
M Source/JavaScriptCore/CMakeLists.txt
Log Message:
-----------
Cherry-pick 313606@main (6cfb79671c10).
https://bugs.webkit.org/show_bug.cgi?id=315226
[CMake] touching a WTF .cpp file should not spend 11s doing LLInt stuff
https://bugs.webkit.org/show_bug.cgi?id=315226
rdar://177555150
Reviewed by Brandon Stewart.
12X speedup (12s => 1s) when touching wtf/Lock.cpp.
* Source/JavaScriptCore/CMakeLists.txt: Changed LLInt extractors to depend
on
headers, and not on all the frameworks (including WTF) on which JSC depends.
The extractors are very specifically designed to work this way.
Otherwise whenever we touch a WTF .cpp file, we dirty the extracter's
dependency,
and then we have to build and run it again.
Canonical link: https://commits.webkit.org/313606@main
Canonical link: https://commits.webkit.org/305877.652@webkitglib/2.52
Commit: 0e3a9a16a766605299aede43b8b4f628d1135166
https://github.com/WebKit/WebKit/commit/0e3a9a16a766605299aede43b8b4f628d1135166
Author: Simon Fraser <[email protected]>
Date: 2026-05-21 (Thu, 21 May 2026)
Changed paths:
A LayoutTests/fast/scrolling/ios/fixed-position-in-vertical-rl-expected.html
A LayoutTests/fast/scrolling/ios/fixed-position-in-vertical-rl.html
M Source/WebCore/page/LocalFrameView.cpp
Log Message:
-----------
Cherry-pick 313573@main (f774c2b1c4f1).
https://bugs.webkit.org/show_bug.cgi?id=315117
[iOS] RTL/position fixed element can lose its contents when the document is
scrolled
https://bugs.webkit.org/show_bug.cgi?id=315117
rdar://177454608
Reviewed by Abrar Rahman Protyasha.
In a side-scrolling RTL page on iOS, scrolling the main frame would cause
content inside
an overflow:scroll inside a fixedpos to disappear. The issue is that we'd
compute an incorrect
layoutViewportRect in `_createVisibleContentRectUpdate`, and this was sent
to the web
process and used to compute layer coverage rects.
`_createVisibleContentRectUpdate` passes the `ConstrainedToDocumentRect`
flag to
`LocalFrameView::computeUpdatedLayoutViewportRect()`, whose constraining
logic was wrong
with RTL where documentBounds.x() goes negative. So use that to clamp,
instead of 0.
I confirmed that the test case for b98e498a0, which added this code, still
works.
Test: fast/scrolling/ios/fixed-position-in-vertical-rl.html
*
LayoutTests/fast/scrolling/ios/fixed-position-in-vertical-rl-expected.html:
Added.
* LayoutTests/fast/scrolling/ios/fixed-position-in-vertical-rl.html: Added.
* Source/WebCore/page/LocalFrameView.cpp:
(WebCore::LocalFrameView::computeUpdatedLayoutViewportRect):
Canonical link: https://commits.webkit.org/313573@main
Canonical link: https://commits.webkit.org/305877.653@webkitglib/2.52
Commit: 1572c7657fd9cdb3ec8d8755d607c649409244f4
https://github.com/WebKit/WebKit/commit/1572c7657fd9cdb3ec8d8755d607c649409244f4
Author: Rupin Mittal <[email protected]>
Date: 2026-05-21 (Thu, 21 May 2026)
Changed paths:
M Source/WebKit/Platform/IPC/MessageReceiverMap.cpp
M Source/WebKit/UIProcess/Extensions/WebExtensionController.cpp
Log Message:
-----------
Cherry-pick 313494@main (825d9df3072f).
https://bugs.webkit.org/show_bug.cgi?id=314930
StabilityTracer: Crash in IPC::MessageReceiverMap::invalidate()
https://bugs.webkit.org/show_bug.cgi?id=314930
rdar://177091898
Reviewed by Chris Dumez.
The crash in IPC::MessageReceiverMap::invalidate() is most likely because
either
m_globalMessageReceivers or m_messageReceivers contain a
WeakPtr<MessageReceiver>
that is null and attempting to dereference it to call
willBeRemovedFromMessageReceiverMap()
hits the RELEASE_ASSERT in WeakPtr::operator->().
The MessageReceiver destructor asserts that the MessageReceiver is not in
any
MessageReceiverMap. So these two maps should never contain a null WeakPtr.
But
given that we see this crash and it's not obvious which MessageReceiver is
not
removing itself from a map before destruction, we fix this crash by adding
null
checks in invalidate(). We also add an ASSERT and RELEASE_LOG_FAULT so that
we
can later catch which MessageReceiver is not removing itself from a map.
Even though it's not clear from the crash log alone which MessageReceiver
is not
removing itself from a map, there is a case that we can speculatively fix:
WebExtensionController is added to the map in
WebExtensionController::addProcessPool()
and removed in WebExtensionController::removeProcessPool(). But it seems
possible
that it can be destroyed without removeProcessPool() being called, and its
destructor
does not remove it from the map. This could possibly be the reason for the
crash. So
we ensure that the destructor will remove it.
This is a speculative fix.
* Source/WebKit/Platform/IPC/MessageReceiverMap.cpp:
(IPC::MessageReceiverMap::invalidate):
* Source/WebKit/UIProcess/Extensions/WebExtensionController.cpp:
(WebKit::WebExtensionController::~WebExtensionController):
Canonical link: https://commits.webkit.org/313494@main
Canonical link: https://commits.webkit.org/305877.654@webkitglib/2.52
Commit: ba263efab8b5be32f957313ef80e84f86d94cd41
https://github.com/WebKit/WebKit/commit/ba263efab8b5be32f957313ef80e84f86d94cd41
Author: Vitor Roriz <[email protected]>
Date: 2026-05-21 (Thu, 21 May 2026)
Changed paths:
M Source/WebCore/platform/graphics/FontCascade.cpp
M Tools/TestWebKitAPI/Tests/WebCore/FontCascade.cpp
Log Message:
-----------
Cherry-pick 313458@main (091658231ee4).
https://bugs.webkit.org/show_bug.cgi?id=315062
Pahawh Hmong text is misrendered because it takes the simple text path
https://bugs.webkit.org/show_bug.cgi?id=315062
rdar://167446860
Reviewed by Brent Fulgham.
The supplementary-character table in FontCascade::characterRangeCodePath
does
not include the Pahawh Hmong block (U+16B00 - U+16B8F), so runs containing
those codepoints fall through to the simple text path which does not
position
Pahawh Hmong tone marks correctly. Therefore add the range to the table so
Pahawh Hmong is shaped on the complex text path, which positions the marks
correctly.
* Source/WebCore/platform/graphics/FontCascade.cpp:
(WebCore::FontCascade::characterRangeCodePath):
* Tools/TestWebKitAPI/Tests/WebCore/FontCascade.cpp:
(TestWebKitAPI::surrogatePair):
(TestWebKitAPI::testSupplementaryCodePath):
(TEST):
Canonical link: https://commits.webkit.org/313458@main
Canonical link: https://commits.webkit.org/305877.655@webkitglib/2.52
Commit: 13fffde7fc51bec2bb53d3d73d60112474a45f89
https://github.com/WebKit/WebKit/commit/13fffde7fc51bec2bb53d3d73d60112474a45f89
Author: Basuke Suzuki <[email protected]>
Date: 2026-05-21 (Thu, 21 May 2026)
Changed paths:
M Source/WebCore/loader/DocumentLoader.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/CustomUserAgent.mm
Log Message:
-----------
Cherry-pick 313127@main (9a2a1a1b6932).
https://bugs.webkit.org/show_bug.cgi?id=313542
[WebKit] Apply authoritative User-Agent on redirect after policy callback
https://bugs.webkit.org/show_bug.cgi?id=313542
rdar://176265326
Reviewed by Chris Dumez.
When an application updates the custom User-Agent (via
WKWebView.customUserAgent,
WKWebpagePreferences._customUserAgent, or
WKWebpagePreferences._customUserAgentAsSiteSpecificQuirks) from inside
decidePolicyForNavigationAction for a 302 redirect target, the updated
User-Agent is not applied to the request that actually gets sent to the
server
unless a process swap happens to be triggered by the cross-origin redirect.
In the programmatic webView.load(_:) case there is no committed document
yet,
so the cross-origin redirect does not trigger a process swap. The redirected
ResourceRequest carries the original request's User-Agent header through to
the
WebProcess, and FrameLoader::applyUserAgentIfNeeded() short-circuits because
the header is already present. The request reaches the server with the stale
UA.
In the link-click case, the prior page is already committed, so the
cross-site
redirect triggers PSON. The replacement WebProcess rebuilds the request from
scratch using the current page-level UA, and the fresh value reaches the
server. This is incidental — the non-PSON path needs the same outcome.
Re-apply the authoritative User-Agent inside
DocumentLoader::willSendRequest()'s
navigation-policy completion handler when the decision is to continue the
load.
FrameLoader::userAgent(url) is the same function applyUserAgentIfNeeded()
uses
for initial requests and consults every UA source — storage-access quirks,
WebsitePolicies site-specific-quirks UA, the regular customUserAgent,
InspectorInstrumentation overrides, and the page-level m_userAgent — so
resolving through it here covers all of them on the redirected request too,
including URL-dependent quirks that differ between the initial URL and the
redirect target. The write is skipped when the computed UA is empty or
matches
the header already on the request.
* Source/WebCore/loader/DocumentLoader.cpp:
(WebCore::DocumentLoader::willSendRequest):
* Tools/TestWebKitAPI/Tests/WebKit/WKWebView/CustomUserAgent.mm:
Canonical link: https://commits.webkit.org/313127@main
Canonical link: https://commits.webkit.org/305877.656@webkitglib/2.52
Commit: 3621a3fadb652167cb31e24384455cb0f8f8ddf4
https://github.com/WebKit/WebKit/commit/3621a3fadb652167cb31e24384455cb0f8f8ddf4
Author: Chris Dumez <[email protected]>
Date: 2026-05-21 (Thu, 21 May 2026)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp
M Source/WebKit/NetworkProcess/NetworkResourceLoader.h
Log Message:
-----------
Cherry-pick 313118@main (071edf4eff8a).
https://bugs.webkit.org/show_bug.cgi?id=314243
RELEASE ASSERT:
http/tests/security/contentSecurityPolicy/multipart-three-part.py is a flaky
crash
https://bugs.webkit.org/show_bug.cgi?id=314243
rdar://169360779
Reviewed by Brent Fulgham and Brady Eidson.
http/tests/security/contentSecurityPolicy/multipart-three-part.py is
flaky because NetworkResourceLoader::didReceiveResponse() sometimes
overwrites m_responseCompletionHandler before the previous one has been
called, hitting the CompletionHandler destructor assertion.
For a multipart/x-mixed-replace main resource, the network layer can
deliver follow-up parts via didReceiveResponse() before the WebProcess
has answered ContinueDidReceiveResponse for the first part. The first
part's round-trip is async because it goes through
DocumentLoader::responseReceived() -> checkContentPolicy(), which IPCs
to the UIProcess. Assigning the new completion handler over the still-
pending one destroyed it without invoking it, asserting in
CompletionHandler's destructor.
Replace the single m_responseCompletionHandler with a Deque so each
incoming response queues its own handler, and each ContinueDidReceive-
Response IPC drains the front of the queue. This mirrors the WebProcess
flow (it processes each part in order, sending one ContinueDidReceive-
Response per approved part), so per-part validation is preserved. On
loader teardown / convertToDownload, any remaining handlers are drained
with PolicyAction::Ignore.
No new tests, covered by existing test.
* Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp:
(WebKit::NetworkResourceLoader::~NetworkResourceLoader):
(WebKit::NetworkResourceLoader::convertToDownload):
(WebKit::NetworkResourceLoader::transferToNewWebProcess):
(WebKit::NetworkResourceLoader::didReceiveResponse):
(WebKit::NetworkResourceLoader::continueDidReceiveResponse):
* Source/WebKit/NetworkProcess/NetworkResourceLoader.h:
Canonical link: https://commits.webkit.org/313118@main
Canonical link: https://commits.webkit.org/305877.657@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/63e41944a88d...3621a3fadb65
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
