Try to avoid creating the default WKWebsiteDataStore until its actually needed Clients can use WebKit without ever referencing the default data store, so we shouldn't create it in those cases.
<rdar://problem/33164453>
Created attachment 320187 [details] Patch
Comment on attachment 320187 [details] Patch Attachment 320187 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/4479551 New failing tests: imported/w3c/web-platform-tests/IndexedDB/idbobjectstore-rename-store.html inspector/indexeddb/clearObjectStore.html inspector/indexeddb/requestDatabaseNames.html storage/indexeddb/modern/blob-svg-image.html storage/indexeddb/modern/blob-cursor.html inspector/indexeddb/requestData.html inspector/indexeddb/deleteDatabaseNamesWithSpace.html imported/w3c/web-platform-tests/IndexedDB/keygenerator-explicit.html
Created attachment 320193 [details] Archive of layout-test-results from ews105 for mac-elcapitan-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews105 Port: mac-elcapitan-wk2 Platform: Mac OS X 10.11.6
Created attachment 320194 [details] Patch
Created attachment 320348 [details] Patch
Had to make some "pending cookie" changes to fix a failing API test. One last EWS run.
Oh... maybe the WK2 layotuttests are a real problem too. Exploring.
(In reply to Brady Eidson from comment #8) > Oh... maybe the WK2 layotuttests are a real problem too. Exploring. Cant reproduce any locally, so I think changes I made to fix API tests could've had an effect.
Comment on attachment 320348 [details] Patch Clearing flags on attachment: 320348 Committed r221834: <http://trac.webkit.org/changeset/221834>
All reviewed patches have been landed. Closing bug.
Comment on attachment 320348 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=320348&action=review > Source/WebKit/UIProcess/API/Cocoa/WKWebsiteDataStorePrivate.h:41 > ++ (BOOL)_defaultDataStoreExists; This should have been annotated with WK_API_AVAILABLE