Drop support for NSURLCache in WebKit2 now that the WebKit network cache is stable.
Created attachment 341315 [details] Patch
Also avoids initializing a NSURLCache in the UIProcess: Sample Count, Samples %, CPU %, Symbol 11, 0.1%, 0.1%, WebKit::WebProcessPool::ensureNetworkProcess(WebKit::WebsiteDataStore*) (in WebKit) 5, 0.0%, 0.0%, WebKit::WebProcessPool::platformInitializeNetworkProcess(WebKit::NetworkProcessCreationParameters&) (in WebKit) 4, 0.0%, 0.0%, +[NSURLCache sharedURLCache] (in CFNetwork) 4, 0.0%, 0.0%, -[NSURLCache initWithMemoryCapacity:diskCapacity:diskPath:] (in CFNetwork) 4, 0.0%, 0.0%, __CFURLCacheCreateInternal(__CFAllocator const*, long, long, __CFString const*, bool, bool) (in CFNetwork) 3, 0.0%, 0.0%, __CFURLCache::createNSURLStorageClient(__CFString const*, long, std::__1::shared_ptr<__CFURLCache>) (in CFNetwork) 3, 0.0%, 0.0%, -[NSURLCacheDBReader openAndPrepareReadCacheDB] (in CFNetwork) 3, 0.0%, 0.0%, -[NSURLCacheDBReader _prepareDBSelectStatements] (in CFNetwork) 3, 0.0%, 0.0%, sqlite3_exec (in libsqlite3.dylib)
Comment on attachment 341315 [details] Patch r=me
Comment on attachment 341315 [details] Patch Clearing flags on attachment: 341315 Committed r232201: <https://trac.webkit.org/changeset/232201>
All reviewed patches have been landed. Closing bug.
<rdar://problem/40566377>
Do we need to find a place to do a one-time "migration" deletion of any NSURLCache that happens to have been left behind by an older version of WebKit?
(In reply to Darin Adler from comment #7) > Do we need to find a place to do a one-time "migration" deletion of any > NSURLCache that happens to have been left behind by an older version of > WebKit? I think that would be a good idea. (We probably should have done this when we first enabled the WebKit HTTP cache.)
I'd like to know if this commit could have caused the following behavior change in iOS UIWebViews. In a UIWebView delegate method webViewDidFinishLoad: I have the following code: NSCachedURLResponse *cachedResponse = [[NSURLCache sharedURLCache] cachedResponseForRequest:webView.request]; For the same request, In iOS 11.4 the cachedResponse is non-nil. In iOS 12.1 the cachedResponse is nil. Should I create a new bug ticket and/or create a radar for this? Our real use case is that in our SDK we swizzle webViewDidFinishLoad: and call cachedResponseForRequest: to track the response status code. Any response appreciated. Thanks
(In reply to Donnie from comment #9) > I'd like to know if this commit could have caused the following behavior > change in iOS UIWebViews. > > In a UIWebView delegate method webViewDidFinishLoad: I have the following > code: > > NSCachedURLResponse *cachedResponse = [[NSURLCache sharedURLCache] > cachedResponseForRequest:webView.request]; > > For the same request, > In iOS 11.4 the cachedResponse is non-nil. > In iOS 12.1 the cachedResponse is nil. > > Should I create a new bug ticket and/or create a radar for this? > > Our real use case is that in our SDK we swizzle webViewDidFinishLoad: and > call cachedResponseForRequest: to track the response status code. > > Any response appreciated. > Thanks No, this change had no impact on UIWebView, only WKWebView.
(In reply to Chris Dumez from comment #10) > No, this change had no impact on UIWebView, only WKWebView. Thanks for the quick confirmation! Is my issue a WebKit-related issue or nothing to do with WebKit?
(In reply to Donnie from comment #11) > (In reply to Chris Dumez from comment #10) > > No, this change had no impact on UIWebView, only WKWebView. > > Thanks for the quick confirmation! > > Is my issue a WebKit-related issue or nothing to do with WebKit? Adding Alex in cc. Sounds to me like it could be due to a CFNetwork change but Alex May know more.
I'm not aware of any change that would've affected Donnie's use case, but that doesn't mean there isn't one. We would appreciate migration to WKWebView or a radar with a description of any blockers for doing so and what their use case is.
Thanks Alex. I created rdar://46828356 (https://openradar.appspot.com/radar?id=5027499947851776) Our team provides a performance tracking SDK to other apps in our company so we'd still like to support tracking response status codes in UIWebViews for those apps still using them.