Steps to reproduce: 1. Create a WebView. 2. Do NOT use webkit_cookie_manager_set_persistent_storage(). This will keep cookies in memory without saving them to disk. 3. Add some cookies, either navigating to a site that sets them, or through WebKitCookieManager. 4. Kill the NetworkProcess. 5. Call webkit_web_view_reload(). Expected outcome: The cookies set in (3.) are sent to the server when the reload happens in (5.) and a new NetworkProcess is spawned. Actual outcome: No cookies at all are sent to the server in (5.) when reloading.
While the most obvious case of cookies being thrown over the cliff happens when no persistence is configured for the cookie jar, even after persistence is configured the session cookies will be lost when the NetworkProcess dies. The reason why not all of them get lost in this case is that cookies which have been persisted to disk get reloaded from the “cookies.txt” text file or from SQLite when a new NetworkProcess is spawned when persistence is configured. This is because session cookies are never persisted. From my point of view it is a reasonable expectation that a fresh NetworkProcess will have the same set of cookies as the old one. The fact that non-persisted cookies are kept in memory by the NetworkProcess is an implementation detail, and e.g. when using the WebKitCookieManager to manually add a cookie, users of the public API will expect that such a cookie will be always there regardless of how many times a NetworkProcess is spawned under the hood.
It looks like bug #88441 might be related, though that one is from the times when cookies (and resource loading) were handled by the WebProcess.
FWIW I wouldn't expect cookies to survive a network process crash. (I'm actually surprised to learn that WebKit is capable of restarting the network process at all.) To improve this you'd need to sync the cookie store between web process and UI process, which doesn't seem desirable to me.
(In reply to Michael Catanzaro from comment #3) > FWIW I wouldn't expect cookies to survive a network process crash. (I'm > actually surprised to learn that WebKit is capable of restarting the network > process at all.) [...] There is no reason why respawning of the NetworkProcess wouldn't work, as far as I know. If it can be done for the WebProcess, why not for others? It strikes me as a good think to make WebKit more resilient :) > [...] To improve this you'd need to sync the cookie store between > web process and UI process, which doesn't seem desirable to me. The lifecycle of the network process is hidden way below the public API. If a cookie is added through the API (WebKitCookieManager), next the network process dies, when retrieving the list of cookies afterwards it is a reasonable expectation that the list includes that one cookie. I'll give you another example why I think that losing the cookies when a fresh NetworkProcess starts is bad: imagine you have a WebKit based browser on Android, where processes may be killed at any time for backgrounded applications... you would expect that your log-ins to websites that use cookies would continue working when you bring back the browser to the foreground and the NetworkProcess is spawned again.
I think fixing this is more effort than it's worth. We don't expect the network process to die, and losing some cookies is hardly a big deal if it does.
(In reply to Michael Catanzaro from comment #5) > I think fixing this is more effort than it's worth. We don't expect the > network process to die, and losing some cookies is hardly a big deal if it > does. Hm, nowadays WebKit actually can recover perfectly fine from a network process crash, just like it can recover from a web process crash. But I lose cookies after a network process crash even though I have a persistent cookie store. It's annoying, and I don't like 2019 Michael's opinion on the matter. ;)