[WK2] API::Navigation objects are leaked on history navigation to HistoryItems in PageCache
https://bugs.webkit.org/show_bug.cgi?id=145948
Reviewed by Darin Adler.
Source/WebCore:
API::Navigation objects were leaked on history navigation to
HistoryItems in PageCache. In such case, we would create 2 Navigation
objects instead of 1 and the first one would be leaked. The reason
we create the second one is because we fail to pass along the
navigationID from the UIProcess to the WebProcess and then back to the
UIProcess. On the IPC back to the UIProcess, the navigationID ends up
being 0 so the UIProcess creates a new Navigation object, thinking that
the load was triggered by the WebContent process.
We now pass along the navigationID, even if the HistoryItem is in the
PageCache and we end up reusing the cached DocumentLoader, instead of
creating a new one. A new updateCachedDocumentLoader() delegate is
added to the FrameLoaderClient, similarly to the pre-existing
createDocumentLoader() but for the case where the DocumentLoader gets
reused.
* loader/EmptyClients.h:
* loader/FrameLoader.cpp:
(WebCore::FrameLoader::loadDifferentDocumentItem):
* loader/FrameLoaderClient.h:
Source/WebKit/mac:
Add empty implementation for new
FrameLoaderClient::updatedCachedDocumentLoader().
* WebCoreSupport/WebFrameLoaderClient.h:
Source/WebKit/win:
Add empty implementation for new
FrameLoaderClient::updatedCachedDocumentLoader().
* WebCoreSupport/WebFrameLoaderClient.h:
Source/WebKit2:
API::Navigation objects were leaked on history navigation to
HistoryItems in PageCache. In such case, we would create 2 Navigation
objects instead of 1 and the first one would be leaked. The reason
we create the second one is because we fail to pass along the
navigationID from the UIProcess to the WebProcess and then back to the
UIProcess. On the IPC back to the UIProcess, the navigationID ends up
being 0 so the UIProcess creates a new Navigation object, thinking that
the load was triggered by the WebContent process.
We now pass along the navigationID, even if the HistoryItem is in the
PageCache and we end up reusing the cached DocumentLoader, instead of
creating a new one. A new updateCachedDocumentLoader() delegate is
added to the FrameLoaderClient, similarly to the pre-existing
createDocumentLoader() but for the case where the DocumentLoader gets
reused.
* WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:
(WebKit::WebFrameLoaderClient::updateCachedDocumentLoader):
* WebProcess/WebCoreSupport/WebFrameLoaderClient.h:
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::goForward):
(WebKit::WebPage::goBack):
(WebKit::WebPage::goToBackForwardItem):
(WebKit::WebPage::updateCachedDocumentLoader):
* WebProcess/WebPage/WebPage.h:
git-svn-id: http://svn.webkit.org/repository/webkit/trunk@185542 268f45cc-cd09-0410-ab3c-d52691b4dbfc
diff --git a/Source/WebCore/loader/FrameLoader.cpp b/Source/WebCore/loader/FrameLoader.cpp
index 628e67d..2ef9500 100644
--- a/Source/WebCore/loader/FrameLoader.cpp
+++ b/Source/WebCore/loader/FrameLoader.cpp
@@ -3177,6 +3177,7 @@
if (CachedPage* cachedPage = PageCache::singleton().get(item, m_frame.page())) {
auto documentLoader = cachedPage->documentLoader();
+ m_client.updateCachedDocumentLoader(*documentLoader);
documentLoader->setTriggeringAction(NavigationAction(documentLoader->request(), loadType, false));
documentLoader->setLastCheckedRequest(ResourceRequest());
loadWithDocumentLoader(documentLoader, loadType, 0, AllowNavigationToInvalidURL::Yes);
