Bug 142389 - Remove willDestroyFrame in WKBundlePageLoaderClient
Summary: Remove willDestroyFrame in WKBundlePageLoaderClient
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-06 00:37 PST by Carlos Garcia Campos
Modified: 2015-03-08 00:10 PST (History)
3 users (show)

See Also:


Attachments
Patch (8.19 KB, patch)
2015-03-07 00:57 PST, Carlos Garcia Campos
andersca: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Carlos Garcia Campos 2015-03-06 00:37:29 PST
I added willDestroyFrame in r154540 but I realized recently (see bug #141641) that it has never actually worked :-( Adding the callback to WKBundlePageLoaderClient was the first mistake, since frames are handled by WebProcess and DidDestroyFrame message is indeed a WebProcessProxy not a WebPageProxyProxy one. Second mistake was calling the callback from WebFrameLoaderClient::frameLoaderDestroyed(), since at that point the frame has already been detached from the page and so WebFrame::page() always returns nullptr. So this in fact dead code. And since r180211 nobody is using it. 
My first idea was to deprecate the method and remove the dead code, but since there aren't any new versions of WKBundlePageLoaderClient, and I guess nobody apart from WebKit internally is using it, maybe we can just remove it?
Comment 1 Carlos Garcia Campos 2015-03-06 08:44:53 PST
I'll make it unavailable as suggested by Anders on IRC
Comment 2 Carlos Garcia Campos 2015-03-07 00:57:49 PST
Created attachment 248147 [details]
Patch
Comment 3 Carlos Garcia Campos 2015-03-08 00:10:57 PST
Committed r181222: <http://trac.webkit.org/changeset/181222>