Bug 44726 - WebFrameProxies aren't destroyed until a page is destroyed
Summary: WebFrameProxies aren't destroyed until a page is destroyed
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Alexey Proskuryakov
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2010-08-26 15:35 PDT by Alexey Proskuryakov
Modified: 2010-08-26 16:04 PDT (History)
2 users (show)

See Also:

Attachments
proposed patch (24.50 KB, patch)
2010-08-26 15:41 PDT, Alexey Proskuryakov 		sam: review+
Details | Formatted Diff | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey Proskuryakov 2010-08-26 15:35:12 PDT 
There is no code that would destroy WebFrameProxies earlier than the page they were created in goes away.

<rdar://problem/8359858>
Comment 1 Alexey Proskuryakov 2010-08-26 15:41:39 PDT 
Created attachment 65633 [details]
proposed patch
Comment 2 Sam Weinig 2010-08-26 15:52:51 PDT 
Comment on attachment 65633 [details]
proposed patch

Nice. I was kind of assuming we were going to use the detachFromParent FrameLoaderClient functions, but I like this approach. Are we going to need/want a way to signal that a Frame has changed Pages in the WebKit2 API?

r=me
Comment 3 Alexey Proskuryakov 2010-08-26 16:02:00 PDT 
> Are we going to need/want a way to signal that a Frame has changed Pages in the WebKit2 API?

I don't know, but there is a special FrameLoaderClient call for changing documents, which we need to implement anyway - didTransferChildFrameToNewDocument().
Comment 4 Alexey Proskuryakov 2010-08-26 16:04:04 PDT 
Committed <http://trac.webkit.org/changeset/66146>.