Steps to reproduce: 1. Create a WKWebViewConfiguration configuration 2. Set processPool for configuration 3. Set a session cookie for domain apple.com to defaultDataStore 4. Create a webView with the configuration 5. Load apple.com in the webView, and check if the session cookie is in cookie storage via web inspector
Created attachment 346227 [details] Patch
Comment on attachment 346227 [details] Patch Attachment 346227 [details] did not pass win-ews (win): Output: https://webkit-queues.webkit.org/results/8720650 New failing tests: imported/blink/transitions/unprefixed-transform.html legacy-animation-engine/imported/blink/transitions/unprefixed-transform.html
Created attachment 346262 [details] Archive of layout-test-results from ews205 for win-future The attached test failures were seen while running run-webkit-tests on the win-ews. Bot: ews205 Port: win-future Platform: CYGWIN_NT-6.1-2.9.0-0.318-5-3-x86_64-64bit
Comment on attachment 346227 [details] Patch r=me
Comment on attachment 346227 [details] Patch Clearing flags on attachment: 346227 Committed r234517: <https://trac.webkit.org/changeset/234517>
All reviewed patches have been landed. Closing bug.
<rdar://problem/42875686>
(In reply to WebKit Commit Bot from comment #5) > Comment on attachment 346227 [details] > Patch > > Clearing flags on attachment: 346227 > > Committed r234517: <https://trac.webkit.org/changeset/234517> Looks like this change broke API tests on iOS https://build.webkit.org/builders/Apple%20iOS%2011%20Simulator%20Release%20WK2%20(Tests)/builds/6594/steps/run-api-tests/logs/stdio TestWebKitAPI.WebKit.WKHTTPCookieStoreWithoutProcessPool /Volumes/Data/slave/ios-simulator-11-release/build/Tools/TestWebKitAPI/Tests/WebKitCocoa/WKHTTPCookieStore.mm:473 Value of: message.UTF8String Actual: "SessionCookieName=CookieValue" Expected: "PersistentCookieName=CookieValue; SessionCookieName=CookieValue"
Reverted r234517 for reason: Caused API test failures on iOS Committed r234561: <https://trac.webkit.org/changeset/234561>
The test is failing because: for an existing processPool, registerForNewProcessPoolNotifications won't be called, so we don't do flushCookieStore and persistent cookies are not written to file for synchronization. We could do a workaround fix for this, but since we are going to do a complete fix by always launching network process whenever needed, and this bug seems to have little impact now. I think we could hold it for later.