You need to
before you can comment on or make changes to this bug.
Created an attachment (id=45337) [details]
WebKit clients can currently cleanly get rid of a WebView in two ways.
2) DestroyWindow(webViewHWND) (can be swapped with (1))
We'd like clients to be able to get rid of a WebView just by releasing
the last reference to it. This patch gets us a little closer to that
by removing step B2 above (though calling DestroyWindow in this case
is harmless). A future patch will make steps A1 and B1 unnecessary, as
Fixes <rdar://problem/7374218> Crash in WebView::updateActiveState
when closing "Welcome to iTunes" window
Reviewed by NOBODY (OOPS!).
(WebView::~WebView): Call setIsBeingDestroyed() so that we won't be
ref'd by our WndProc, which would result in this destructor being
(WebView::close): Moved the call to revokeDragDrop here...
(WebView::WebViewWndProc): ...from here. This is important in order to
release the reference that OLE holds while we're registered as a drop
target. Otherwise, clients that call IWebView::close but not
DestroyWindow would leak the WebView.
Made these private, and added a comment about what isBeingDestroyed()
3 files changed, 52 insertions(+), 5 deletions(-)
style-queue ran check-webkit-style on attachment 45337 [details] without any errors.
(From update of attachment 45337 [details])
I'm going to try tackling this a different way.
Created an attachment (id=45912) [details]
Make it safe to call IWebView::close when IWebView::initWithFrame hasn't been called
style-queue ran check-webkit-style on attachment 45912 [details] without any errors.
Created an attachment (id=45916) [details]
Make IWebView::close and destroying a WebView's HWND optional for WebKit clients
(From update of attachment 45912 [details])
Looks sane to me too.
Committed r52829: <http://trac.webkit.org/changeset/52829>
Committed r52830: <http://trac.webkit.org/changeset/52830>