Bug 185990 - Drop support for NSURLCache in WebKit2
Summary: Drop support for NSURLCache in WebKit2
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Chris Dumez
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-05-25 13:05 PDT by Chris Dumez
Modified: 2018-12-18 18:15 PST (History)
7 users (show)

See Also:


Attachments
Patch (35.13 KB, patch)
2018-05-25 13:08 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Dumez 2018-05-25 13:05:50 PDT
Drop support for NSURLCache in WebKit2 now that the WebKit network cache is stable.
Comment 1 Chris Dumez 2018-05-25 13:08:04 PDT
Created attachment 341315 [details]
Patch
Comment 2 Chris Dumez 2018-05-25 13:09:32 PDT
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 3 Geoffrey Garen 2018-05-25 13:17:18 PDT
Comment on attachment 341315 [details]
Patch

r=me
Comment 4 WebKit Commit Bot 2018-05-25 14:27:25 PDT
Comment on attachment 341315 [details]
Patch

Clearing flags on attachment: 341315

Committed r232201: <https://trac.webkit.org/changeset/232201>
Comment 5 WebKit Commit Bot 2018-05-25 14:27:26 PDT
All reviewed patches have been landed.  Closing bug.
Comment 6 Radar WebKit Bug Importer 2018-05-25 14:37:52 PDT
<rdar://problem/40566377>
Comment 7 Darin Adler 2018-05-25 21:30:57 PDT
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?
Comment 8 Geoffrey Garen 2018-05-29 11:18:34 PDT
(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.)
Comment 9 Donnie 2018-12-16 21:18:10 PST
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
Comment 10 Chris Dumez 2018-12-16 21:57:59 PST
(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.
Comment 11 Donnie 2018-12-16 22:12:00 PST
(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?
Comment 12 Chris Dumez 2018-12-16 22:21:37 PST
(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.
Comment 13 Alex Christensen 2018-12-17 10:44:33 PST
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.
Comment 14 Donnie 2018-12-18 18:15:50 PST
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.