CODEWITHSUNDEEP
iosobjective-cautomatic-ref-countingwkwebview
Heath Borders
Heath Borders

Reputation: 32117

WKWebView subclass crashes on dealloc

When my WKWebView subclass (MyWKWebView) deallocs, it crashes thusly:

2016-05-05 15:40:08.814 MyApp[15559:202920] -[MyViewController dealloc]: In MyViewController dealloc objc[15559]: Cannot form weak reference to instance (0x7f9db7f0dbf0) of class MyWKWebView. It is possible that this object was over-released, or is in the process of deallocation.

I have no weak references to the MyWKWebView, but the MyWKWebView itself holds a weak reference to my UIViewController subclass (MyViewController), which owns MyWKWebView.

Thoughts?

Upvotes: 1

Views: 980

Answers (1)

Heath Borders
Heath Borders

Reputation: 32117

An apparently important detail I didn't realize: my WKWebView subclass (MyWKWebView) conforms to UIScrollViewDelegate. (I'm trying to make WKWebView API-compatible with UIWebView so I can easily swap them between iOS7 and later versions.)

This matters because WKWebView already conforms to UIScrollViewDelegate, though it doesn't say so in the header:

#if TARGET_OS_IPHONE
WK_CLASS_AVAILABLE(10_10, 8_0)
@interface WKWebView : UIView
#else

However, if you look in the WKWebViewInternal.h header, we see a suspicious category:

@interface WKWebView () WK_WEB_VIEW_PROTOCOLS

and if we look further up in the file, we see that WK_WEB_VIEW_PROTOCOLS is <UIScrollViewDelegate> on iOS:

#if PLATFORM(IOS)
#define WK_WEB_VIEW_PROTOCOLS <UIScrollViewDelegate>
#endif

I can't find anywhere that would explicitly cause an overrelease, but I'm surely screwing up something in WKWebView by not allowing its proper UIScrollViewDelegate methods to be called.

The workaround is to implement UIScrollViewDelegate in a separate object.

Upvotes: 2

Related Questions