Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: 4c99752420d8c35dfc2c0f209a2897a84afeaca0
https://github.com/WebKit/WebKit/commit/4c99752420d8c35dfc2c0f209a2897a84afeaca0
Author: Said Abou-Hallawa <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
M Source/WebCore/platform/graphics/DestinationColorSpace.cpp
M Source/WebCore/platform/graphics/DestinationColorSpace.h
M Source/WebCore/platform/graphics/PixelBufferConversion.cpp
M Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in
M Tools/TestWebKitAPI/Tests/WebCore/ImageBufferTests.cpp
Log Message:
-----------
Cherry-pick 8e2784fd0807. https://bugs.webkit.org/show_bug.cgi?id=312945
GetPixelBuffer should zeroFill the destination if any error happens
https://bugs.webkit.org/show_bug.cgi?id=312945
rdar://174640273
Reviewed by Kimmo Kinnunen.
RemoteImageBuffer fails to GetPixelBuffer if the destination colorSpace is
non-RGB
model (e.g. kCGColorSpaceGenericCMYK). In this case the PixelBuffer is allocated
but never be initialized. So stale heap can be exposed to callers.
To fix this an IPC validator is needed to ensure the colorSpace is indeed RGB
model.
And to handle other possible unknown failures, the destination PixelBuffer will
be zero-filled if vImage fails to do the conversion the colorSpace conversion.
* Source/WebCore/platform/graphics/DestinationColorSpace.cpp:
(WebCore::DestinationColorSpace::usesRGBColorModel const):
* Source/WebCore/platform/graphics/DestinationColorSpace.h:
* Source/WebCore/platform/graphics/PixelBufferConversion.cpp:
(WebCore::convertImagePixelsAccelerated):
* Source/WebKit/Shared/WebCoreArgumentCoders.serialization.in:
* Tools/TestWebKitAPI/Tests/WebCore/ImageBufferTests.cpp:
(TestWebKitAPI::TEST(ImageBufferTests, GetPixelBufferAllZeros)):
Identifier: 305413.874@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.932@webkitglib/2.52
Commit: b85f1a5499d0113f8a05149b58ac21641ddd2712
https://github.com/WebKit/WebKit/commit/b85f1a5499d0113f8a05149b58ac21641ddd2712
Author: Dan Glastonbury <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
A LayoutTests/webxr/xr-isSessionSupported-detached-iframe-crash-expected.txt
A LayoutTests/webxr/xr-isSessionSupported-detached-iframe-crash.html
M Source/WebCore/Modules/webxr/WebXRSystem.cpp
Log Message:
-----------
Cherry-pick 0e75e33398b8. https://bugs.webkit.org/show_bug.cgi?id=312945
[WebXR] Use-after-free of WebXRSystem in callbacks re-posted from
ensureImmersiveXRDeviceIsSelected
rdar://175674581
Reviewed by Mike Wyrzykowski.
WebXRSystem::ensureImmersiveXRDeviceIsSelected sends an async
EnumerateImmersiveXRDevices IPC whose reply lambda holds protectedThis = Ref
{ *this }, but inside that lambda a makeScopeExit re-posts the caller's callback
via callOnMainThread(). The reply lambda is then destroyed and protectedThis
drops. The callbacks supplied by isSessionSupported, obtainCurrentDevice and
requestSession capture only raw |this|, so the queued main-thread task holds no
ownership of the WebXRSystem. If iframe removal + GC tears down
NavigatorWebXR::m_xr between the protectedThis drop and the pending
callOnMainThread task, the task reads freed memory.
Separately, the RequestPermissionOnSessionFeatures reply lambda in
requestSession writes m_pendingImmersiveSession through raw |this| in its
!weakThis branch.
Fix by capturing protectedThis = protect(*this) in the isSessionSupported,
obtainCurrentDevice and requestSession callbacks so they keep the WebXRSystem
alive across the callOnMainThread re-post, and by splitting the !weakThis
early-return in the inner requestSession permission reply so it does not touch
members after the object is gone.
Test: webxr/xr-isSessionSupported-detached-iframe-crash.html
* LayoutTests/webxr/xr-isSessionSupported-detached-iframe-crash-expected.txt:
Added.
* LayoutTests/webxr/xr-isSessionSupported-detached-iframe-crash.html: Added.
* Source/WebCore/Modules/webxr/WebXRSystem.cpp:
(WebCore::WebXRSystem::obtainCurrentDevice):
(WebCore::WebXRSystem::isSessionSupported):
(WebCore::WebXRSystem::requestSession):
Identifier: 305413.841@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.933@webkitglib/2.52
Commit: 8e6f42a7da28f8c70f933311b2465a6226ff82ab
https://github.com/WebKit/WebKit/commit/8e6f42a7da28f8c70f933311b2465a6226ff82ab
Author: Chris Dumez <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
A
LayoutTests/ipc/use-redirection-for-current-navigation-message-check-expected.txt
A LayoutTests/ipc/use-redirection-for-current-navigation-message-check.html
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
M Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp
Log Message:
-----------
Cherry-pick a547e707161f. https://bugs.webkit.org/show_bug.cgi?id=314862
[WebKit Networking] continueWillSendRequest m_redirectionForCurrentNavigation
early-return reaches Cache::storeRedirect with unrestored cachePartition
https://bugs.webkit.org/show_bug.cgi?id=314862
rdar://176914483
Reviewed by Alex Christensen.
A compromised WebContent process can poison the Network Process persistent
disk cache for an arbitrary cross-origin partition.
NetworkConnectionToWebProcess::useRedirectionForCurrentNavigation accepts a
WebContent-supplied ResourceResponse with no validation and stashes it on the
loader as m_redirectionForCurrentNavigation. When the loader's WillSendRequest
async reply later delivers a WebContent-supplied ResourceRequest,
NetworkResourceLoader::continueWillSendRequest takes the
m_redirectionForCurrentNavigation early-return into willSendRedirectedRequest
*before* the setCachePartition(originalRequest().cachePartition()) restore,
so NetworkCache::Cache::storeRedirect keys the on-disk record by the
unvalidated WebContent-chosen {cachePartition, url} and persists the
WebContent-supplied 301 with WebContent-chosen Location:.
Fix this by:
1. Hoisting the setCachePolicy/setCachePartition restore to the top of
continueWillSendRequest so every path through the function — including the
m_redirectionForCurrentNavigation, service-worker and m_shouldRestartLoad
early returns — uses the original (Network-Process-side) cache partition,
never the value round-tripped through the WebContent process.
2. Promoting the debug ASSERT(isMainFrameLoad()) and
ASSERT(response.isRedirection()) at the
NetworkConnectionToWebProcess::useRedirectionForCurrentNavigation IPC
entry point to MESSAGE_CHECKs. The legitimate sender
(WebPage::useRedirectionForCurrentNavigation, driven by
RedirectSOAuthorizationSession in the UI process) only ever targets the
main-frame main-resource loader with a redirection response; anything else
is a compromised WebContent process.
Test: ipc/use-redirection-for-current-navigation-message-check.html
*
LayoutTests/ipc/use-redirection-for-current-navigation-message-check-expected.txt:
Added.
* LayoutTests/ipc/use-redirection-for-current-navigation-message-check.html:
Added.
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::useRedirectionForCurrentNavigation):
* Source/WebKit/NetworkProcess/NetworkResourceLoader.cpp:
(WebKit::NetworkResourceLoader::continueWillSendRequest):
Identifier: 305413.915@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.934@webkitglib/2.52
Commit: 89f84f661bd09240afd3be219b3ab8b8ab77ab55
https://github.com/WebKit/WebKit/commit/89f84f661bd09240afd3be219b3ab8b8ab77ab55
Author: Zak Ridouh <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
A
LayoutTests/ipc/rgba16f-getpixelbuffer-colorspace-mismatch-heap-disclosure-expected.txt
A
LayoutTests/ipc/rgba16f-getpixelbuffer-colorspace-mismatch-heap-disclosure.html
M Source/WebCore/platform/graphics/PixelBufferConversion.cpp
Log Message:
-----------
Cherry-pick e7a0eda7b7ff. https://bugs.webkit.org/show_bug.cgi?id=314590
Uninitialized-heap disclosure in convertImagePixelsFromFloat16ToFloat16 via
color-space early-return
<https://bugs.webkit.org/show_bug.cgi?id=314590>
<rdar://176483321>
Reviewed by Gerald Squelart.
convertImagePixelsFromFloat16ToFloat16() early-returned on a color-space
mismatch without writing the destination. The destination buffer is allocated
via JSC::Float16Array::tryCreateUninitialized() and ImageBufferBackend::
getPixelBuffer() only zero-fills on a size mismatch, so an RGBA16F
getPixelBuffer() readback whose output color space differed from the backing
IOSurface's left the destination populated with uninitialized
Gigacage::Primitive heap. RemoteImageBuffer::getPixelBufferWithNewMemory()
then memcpy'd those bytes into WebContent-mapped shared memory causing a
WebContent<->GPUProcess heap disclosure.
Float16<->Float16 color-space conversion is unimplemented (the 8-bit sibling
path also doesn't perform it). Remove the early return so the destination
is always populated with the source pixels (alpha-format conversion applied),
matching the sibling's behavior and closing the disclosure.
Test: ipc/rgba16f-getpixelbuffer-colorspace-mismatch-heap-disclosure.html
*
LayoutTests/ipc/rgba16f-getpixelbuffer-colorspace-mismatch-heap-disclosure-expected.txt:
Added.
*
LayoutTests/ipc/rgba16f-getpixelbuffer-colorspace-mismatch-heap-disclosure.html:
Added.
* Source/WebCore/platform/graphics/PixelBufferConversion.cpp:
(WebCore::convertImagePixelsFromFloat16ToFloat16):
Identifier: 305413.933@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.935@webkitglib/2.52
Commit: c6895bbe30f5139000b30ca99aa82a148acff531
https://github.com/WebKit/WebKit/commit/c6895bbe30f5139000b30ca99aa82a148acff531
Author: Chris Dumez <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
A LayoutTests/ipc/preconnect-to-message-checks-expected.txt
A LayoutTests/ipc/preconnect-to-message-checks.html
M Source/WebKit/CMakeLists.txt
M Source/WebKit/DerivedSources-input.xcfilelist
M Source/WebKit/DerivedSources.make
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.h
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.messages.in
A Source/WebKit/NetworkProcess/PreconnectRequest.h
A Source/WebKit/NetworkProcess/PreconnectRequest.serialization.in
M Source/WebKit/NetworkProcess/PreconnectTask.cpp
M Source/WebKit/Scripts/webkit/messages.py
M Source/WebKit/WebKit.xcodeproj/project.pbxproj
M Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp
M Source/WebKit/WebProcess/WebCoreSupport/WebLocalFrameLoaderClient.cpp
Log Message:
-----------
Cherry-pick 02c6dfb19415. https://bugs.webkit.org/show_bug.cgi?id=314864
[WebKit Networking] missing MESSAGE_CHECK and unvalidated shouldPreconnectOnly
in NetworkConnectionToWebProcess::preconnectTo / sendH2Ping
https://bugs.webkit.org/show_bug.cgi?id=314864
rdar://176911922
Reviewed by Alex Christensen.
NetworkConnectionToWebProcess::preconnectTo and sendH2Ping previously
accepted a full NetworkResourceLoadParameters from WebContent. That
struct carries shouldPreconnectOnly, an httpBody on the request, a
foreign firstPartyForCookies, and many other fields that have no
legitimate use for a preconnect or H2 ping. A compromised WebContent
process could send shouldPreconnectOnly=No together with a file-backed
FormData body and a foreign firstPartyForCookies, and the
NetworkProcess would issue a full credentialed POST that streamed an
arbitrary NetworkProcess-readable file to an attacker-controlled
server. The only guards on this path were two debug ASSERTs.
Fix by replacing the wire types with purpose-built ones that carry
only the fields these operations actually need, and assembling the
NetworkLoadParameters in the NetworkProcess:
- SendH2Ping now takes (URL, webPageProxyID, webPageID, webFrameID,
isNavigatingToAppBoundDomain). The NetworkProcess constructs a fresh
ResourceRequest{url} locally, so no WebContent-supplied httpBody or
shouldPreconnectOnly=No can reach PreconnectTask: the IPC contract
itself enforces what previously needed a MESSAGE_CHECK.
- PreconnectTo now takes a new WebKit::PreconnectRequest struct with
the small set of fields the WebContent legitimately provides
(ResourceRequest, page/frame IDs, storedCredentialsPolicy,
advancedPrivacyProtections, isNavigatingToAppBoundDomain,
preconnectionIdentifier). The NetworkProcess builds the
NetworkLoadParameters and forces shouldPreconnectOnly=Yes. The
ResourceRequest can still carry an httpBody on the wire, so
MESSAGE_CHECK(!request.httpBody()) is retained at the IPC boundary.
PreconnectTask::create keeps the defense-in-depth from the prior
revision (force shouldPreconnectOnly=Yes and clear any httpBody) so a
future caller cannot accidentally reintroduce the issue.
Test: ipc/preconnect-to-message-checks.html
* LayoutTests/ipc/preconnect-to-message-checks-expected.txt:
* LayoutTests/ipc/preconnect-to-message-checks.html: Updated to encode
the new PreconnectRequest wire format with a hostile httpBody.
* Source/WebKit/CMakeLists.txt:
* Source/WebKit/DerivedSources-input.xcfilelist:
* Source/WebKit/DerivedSources.make:
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::sendH2Ping):
(WebKit::NetworkConnectionToWebProcess::preconnectTo):
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.h:
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.messages.in:
* Source/WebKit/NetworkProcess/PreconnectRequest.h: Added.
* Source/WebKit/NetworkProcess/PreconnectRequest.serialization.in: Added.
* Source/WebKit/Scripts/webkit/messages.py: Add PreconnectRequest to
types_that_must_be_moved().
* Source/WebKit/WebKit.xcodeproj/project.pbxproj:
* Source/WebKit/WebProcess/Network/WebLoaderStrategy.cpp:
(WebKit::WebLoaderStrategy::preconnectTo):
* Source/WebKit/WebProcess/WebCoreSupport/WebLocalFrameLoaderClient.cpp:
(WebKit::WebLocalFrameLoaderClient::sendH2Ping):
Identifier: 305413.927@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.936@webkitglib/2.52
Commit: 8c7d58a08d9380f8d3e3b1d4dda8ec0b9c1f5c5b
https://github.com/WebKit/WebKit/commit/8c7d58a08d9380f8d3e3b1d4dda8ec0b9c1f5c5b
Author: Charlie Wolfe <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/LoadAndDecodeImage.mm
Log Message:
-----------
Cherry-pick bc7a427882d4. https://bugs.webkit.org/show_bug.cgi?id=315252
com.apple.WebKit.Networking at Received an invalid message
'NetworkConnectionToWebProcess_LoadImageForDecoding'
https://bugs.webkit.org/show_bug.cgi?id=315252
rdar://177568018
Reviewed by Rupin Mittal.
There are two cases where the MESSAGE_CHECK in
NetworkConnectionToWebProcess::loadImageForDecoding
can still fail after the fix in rdar://176310702:
- A client set an incorrect or empty mainDocumentURL.
- A client called _loadAndDecodeImage: on a WKWebView that has not loaded any
content.
Set firstPartyForCookies in the web process from page->mainFrameURL(), which is
the authoritative
value, and drop the WKWebView-side fallback added in the previous fix. When
mainFrameURL is empty
(no navigation has happened yet, so there is no cookie context), disable
cookies for the request
instead of failing the MESSAGE_CHECK.
Test: Tools/TestWebKitAPI/Tests/WebKitCocoa/LoadAndDecodeImage.mm
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::loadImageForDecoding):
* Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView
_loadAndDecodeImage:constrainedToSize:maximumBytesFromNetwork:completionHandler:]):
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::loadAndDecodeImage):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/LoadAndDecodeImage.mm:
(TestWebKitAPI::TEST(WebKit, LoadAndDecodeImageBeforeAnyNavigation)):
(TestWebKitAPI::TEST(WebKit,
LoadAndDecodeImageWithCallerProvidedDisallowedMainDocumentURL)):
Identifier: 305413.944@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.937@webkitglib/2.52
Commit: aebc89b559d4e38db0b2f6fbcdd876143dbd4cea
https://github.com/WebKit/WebKit/commit/aebc89b559d4e38db0b2f6fbcdd876143dbd4cea
Author: Alex Christensen <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
M Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
Log Message:
-----------
Cherry-pick 82d9c4e4c38b. https://bugs.webkit.org/show_bug.cgi?id=314948
Add MESSAGE_CHECK for cache partition in
NetworkConnectionToWebProcess::scheduleResourceLoad
rdar://176912978
Reviewed by Per Arne Vollan.
It should always be the same as firstPartyForCookies. I'm working to remove
the duplicate info
in https://github.com/WebKit/WebKit/pull/65212 but this is a lower-risk change
that adds the
needed check.
* Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:
(WebKit::NetworkConnectionToWebProcess::scheduleResourceLoad):
Identifier: 305413.965@safari-7624-branch
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.938@webkitglib/2.52
Commit: 7f8890f46deb55305c08d4972c747986540f810a
https://github.com/WebKit/WebKit/commit/7f8890f46deb55305c08d4972c747986540f810a
Author: Chris Dumez <[email protected]>
Date: 2026-07-03 (Fri, 03 Jul 2026)
Changed paths:
M Source/WebKit/UIProcess/ProvisionalPageProxy.cpp
M Source/WebKit/UIProcess/RemotePageProxy.cpp
M Source/WebKit/UIProcess/SuspendedPageProxy.cpp
M Source/WebKit/UIProcess/WebPageProxy.cpp
M Source/WebKit/UIProcess/WebProcessProxy.cpp
M Source/WebKit/UIProcess/WebProcessProxy.h
M Source/WebKit/WebProcess/WebPage/WebPage.cpp
M Source/WebKit/WebProcess/WebPage/WebPage.h
M Source/WebKit/WebProcess/WebPage/WebPage.messages.in
M Source/WebKit/WebProcess/glib/WebProcessGLib.cpp
M Tools/TestWebKitAPI/Tests/WebKitCocoa/RemoteObjectRegistry.h
M Tools/TestWebKitAPI/Tests/WebKitCocoa/RemoteObjectRegistry.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/RemoteObjectRegistryPlugIn.mm
M Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebViewEvaluateJavaScript.mm
Log Message:
-----------
Cherry-pick c753fa7345b6. https://bugs.webkit.org/show_bug.cgi?id=314948
Sign in with Apple unsuccessful and causes reload due to problem - Received an
invalid message 'RemoteObjectRegistry_InvokeMethod'
rdar://178567852
Reviewed by Alex Christensen.
The injected bundle's -webProcessPlugIn:willDestroyBrowserContextController:
hook fires synchronously from WebPage::close() in the WebProcess, and bundle
clients are allowed to invoke a UIProcess-side _WKRemoteObjectRegistry method
from that hook. The resulting RemoteObjectRegistry::InvokeMethod IPC arrives
at the UIProcess after WebPageProxy::close() has synchronously called
WebProcessProxy::removeWebPage(), so the page is no longer in m_pageMap (or
m_remotePages / m_provisionalPages / m_suspendedPages).
WebProcessProxy::handleRemoteObjectRegistryMessage then returned false, which
caused the generated didReceiveMessage to mark the decoder invalid and the
IPC layer to call WebProcessProxy::didReceiveInvalidMessage, terminating an
otherwise well-behaved WebProcess.
To fix this, mark every content process for the page as pending-close before
dispatching Messages::WebPage::Close, and only clear the marker once the
async reply arrives. WebProcessProxy::isAssociatedWithPage already consults
m_pagesPendingClose, so a late-arriving InvokeMethod is now recognized and
delivered to the registry. m_pagesPendingClose is changed from HashSet to
HashCountedSet so the regular close path and the provisional-page-swap close
path compose correctly when both target the same page.
handleRemoteObjectRegistryMessage is reworked to consult isAssociatedWithPage
and look the page up via the global WebPageProxy::fromIdentifier, replacing
the four sequential map walks.
Note that this commit makes the branch more in-line with main after 314178@main.
314178@main already takes care of adding the page to m_pagesPendingClose while
we're sending the WebPage::Close IPC. Also include the fix from 314426@main,
since it fixed a crash introduced by 314178@main.
TLDR: this PR is essentially a merge for 314178@main & 314178@main from
main so that WebProcessProxy::m_pagesPendingClose gets properly populated.
Then WebProcessProxy::handleRemoteObjectRegistryMessage() is updated to
call WebProcessProxy::isAssociatedWithPage() instead of duplicating its
logic. WebProcessProxy::isAssociatedWithPage also has the benefit of
checking m_pagesPendingClose already.
Update WKWebView.EvaluateJavaScriptBlockCrash test expectation to match
313673@main: now that Messages::WebPage::Close is an async-reply message,
the WebProcess is kept alive (via the shutdownPreventingScope held in the
Close reply handler) long enough for the pending evaluateJavaScript IPC to
be processed and reply with a successful empty result, instead of being
cancelled by Connection::cancelAsyncReplyHandlers when the connection is
invalidated. The completion handler is therefore invoked with a nil error,
matching the same test expectation update made in 313673@main.
Tests: RemoteObjectRegistry.InvokeMethodFromBundleDuringPageClose
* Source/WebKit/UIProcess/ProvisionalPageProxy.cpp:
(WebKit::ProvisionalPageProxy::~ProvisionalPageProxy):
* Source/WebKit/UIProcess/RemotePageProxy.cpp:
(WebKit::RemotePageProxy::disconnect):
* Source/WebKit/UIProcess/SuspendedPageProxy.cpp:
(WebKit::SuspendedPageProxy::close):
* Source/WebKit/UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::close):
(WebKit::WebPageProxy::commitProvisionalPage):
* Source/WebKit/UIProcess/WebProcessProxy.cpp:
(WebKit::WebProcessProxy::~WebProcessProxy):
(WebKit::WebProcessProxy::sendPageCloseMessage):
(WebKit::WebProcessProxy::handleRemoteObjectRegistryMessage):
* Source/WebKit/UIProcess/WebProcessProxy.h:
* Source/WebKit/WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::close):
(WebKit::WebPage::closeWithReply): Deleted.
* Source/WebKit/WebProcess/WebPage/WebPage.h:
* Source/WebKit/WebProcess/WebPage/WebPage.messages.in:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/RemoteObjectRegistry.h:
* Tools/TestWebKitAPI/Tests/WebKitCocoa/RemoteObjectRegistry.mm:
(TEST(RemoteObjectRegistry, InvokeMethodFromBundleDuringPageClose)):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/RemoteObjectRegistryPlugIn.mm:
(-[RemoteObjectRegistryPlugIn triggerCallToUIProcessOnClose]):
(-[RemoteObjectRegistryPlugIn
webProcessPlugIn:willDestroyBrowserContextController:]):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebViewEvaluateJavaScript.mm:
(TEST(WKWebView, EvaluateJavaScriptBlockCrash)):
Originally-landed-as: d0f2013438ba
Canonical link: https://commits.webkit.org/305877.939@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/6b0832a5592a...7f8890f46deb
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
