Use a per app directory distructure for website data
Created attachment 231775 [details] Patch
Comment on attachment 231775 [details] Patch r=me too (especially if you fix the differently-scoped-same-name NSURL *url which always makes me slightly nervous)
Created attachment 231892 [details] Patch
Comment on attachment 231892 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=231892&action=review > Source/WebKit2/ChangeLog:9 > + Put Website data in subdirectories of ~/Library/WebKit/<bundle ID>/WebsiteData. website > Source/WebKit2/UIProcess/API/Cocoa/WKProcessPool.mm:125 > + if (![[NSFileManager defaultManager] createDirectoryAtURL:url withIntermediateDirectories:YES attributes:nil error:nullptr]) > + RELEASE_ASSERT_NOT_REACHED(); It doesn’t seem appropriate to assert that directory creation didn’t fail. Certain external conditions, such as permissions on intermediate directories, can make the assertion false.
Committed r169271: <http://trac.webkit.org/changeset/169271>
(In reply to comment #5) > Committed r169271: <http://trac.webkit.org/changeset/169271> This looks like it broke the following API tests on the WK2 debug bots: WKNavigation.DidFailProvisionalNavigation WKNavigation.LoadRequest WKNavigation.NavigationDelegate _WKDownload.CancelDownload _WKDownload.ConvertResponseToDownload _WKDownload.DownloadDelegate _WKDownload.DownloadMissingResource _WKDownload.DownloadRequest _WKDownload.OriginatingWebView For backtraces of the crashes, see: http://build.webkit.org/builders/Apple%20Mavericks%20Debug%20WK2%20%28Tests%29/builds/4851/steps/run-api-tests/logs/stdio For a history of when these failures started, see: http://build.webkit.org/builders/Apple%20Mavericks%20Debug%20WK2%20%28Tests%29?numbuilds=25