The various implementations of WebProcessPool::networkingCachesDirectory(), WebProcessPool::webContentCachesDirectory(), etc., recognize that a process might not be containerized (e.g., system daemons that use WebKit) and so have a clean fallback path for that case.
The GPU Process does not, and so can fail to get a clean cache directory resulting in file access errors and other problems.
We should use the same logic we do in WebContent.
Created attachment 429298 [details]
Created attachment 429303 [details]
This patch is compiled out of Mac builds, so landing now that iOS tests are done.
Committed r277879 (238017@main): <https://commits.webkit.org/238017@main>
All reviewed patches have been landed. Closing bug and clearing flags on attachment 429303 [details].
Comment on attachment 429303 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=429303&action=review
> String path = pathForProcessContainer();
> if (path.isEmpty())
> path = NSHomeDirectory();
> - path = path + "/Library/Cookies";
> + path = path + subpath;
> path = stringByResolvingSymlinksInPath(path);
> return path;
Could improve performance by correctly using makeString.
> + static String cacheDirectoryInContainerOrHomeDirectory(const String& subpath);
This argument should be ASCIILiteral.