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.
<rdar://problem/78288016>
Created attachment 429298 [details] Patch
Created attachment 429303 [details] Patch
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] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=429303&action=review > Source/WebKit/UIProcess/Cocoa/WebProcessPoolCocoa.mm:200 > 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. > Source/WebKit/UIProcess/WebProcessPool.h:514 > + static String cacheDirectoryInContainerOrHomeDirectory(const String& subpath); This argument should be ASCIILiteral.