Currently a fixed location is defined. In real life use case, the path for cookie database must be set by application because cookie database is not protected by any sort of lock. Using in-memory database for default status is much better than silently conflicting.
Also setting a path via environment variable causes another hidden conflict. It should be removed.
Created attachment 363011 [details] PATCH Replace default path generation method with constant.
Comment on attachment 363011 [details] PATCH How will you be able to have persistent cookies?
We have an api to set the database. https://github.com/WebKit/webkit/blob/master/Source/WebCore/platform/network/curl/NetworkStorageSessionCurl.cpp#L72
All green. Ready to land. Review please.
I think this is doing the wrong thing. If you want to make tests not flakey, you should probably hook up NetworkProcess::switchToNewTestingSession. If you want to make different applications not corrupt their cookies, make the default path dependent on the application. If you want to make the same application not corrupt its cookies, have it use the same WebProcessPool-wrapping objects for its WebPageProxy-wrapping objects to make it so there is only one process opening the file at the same time.
(In reply to Alex Christensen from comment #6) > I think this is doing the wrong thing. If you want to make tests not > flakey, you should probably hook up > NetworkProcess::switchToNewTestingSession. Solving a flakiness is an added bonus of the main concern below. > If you want to make different > applications not corrupt their cookies, make the default path dependent on > the application. This is the main concern about this patch. Library doesn't have any information about application. It has to be set explicitly. If the cookie path is prepared from peace of information about application, what the different from passing cookie database provided from application? Maybe we should disable cookie feature until cookie database is explicitly supplied. What do you think? > If you want to make the same application not corrupt its > cookies, have it use the same WebProcessPool-wrapping objects for its > WebPageProxy-wrapping objects to make it so there is only one process > opening the file at the same time. This is not the case for us.