amaitland
commented
3 weeks ago There is this ominous warning in the official documentation for CachePath (https://cef-builds.spotifycdn.com/docs/129.0/structcef__settings__t.html#ad1644a7eb23cad969181db010f007710) that seems preserved in the CefSharp docs.
I've seen a few reports on ceforum that make me question if the CEF documentation reflects the actual behavior.
mitchcapper
Is there an existing issue for this?
CefSharp Version
129.0.12
Operating System
Windows 10
Architecture
x64
.Net Version
.net 8
Implementation
WPF
Reproduction Steps
Using WPF.HwndHost but I would assume it is not limited to that. It is possible I am not fully understanding the new RootCachePath/CachePath relationship but I think I do. Seems to happen with both runtime styles.
In CefSettings I am setting root cache path to c:\ParentDir I am setting cache path to c:\ParentDir\Bingo
Then start the example as normal. c:\ParentDir\Bingo is created but it is empty.
If cache_path is set to null cookies are still stored between sample app restarts but the documentation seems to say this should be incognito mode so clearly cookies shouldn't be preserved.
Moving on I created a custom request context for each instance with cache path set. I modified BrowserTabView and right after InitializeComponent added:
browser.RequestContext = RequestContext.Configure().WithCachePath('PathHere').Create();First I tried null, behavior like above cookies still stored. Then I tried a random value like:
browser.RequestContext = RequestContext.Configure().WithCachePath(Path.Combine(CefExample.RootCachePath,"zibber" + DateTime.Now.Ticks)).Create();This is more interesting. The Zibber random folder is created, it is populated with the profile specific directory set (different dirs than the rootcachepath). Cookies are still shared, even between restarts.
In all cases
chrome://version/shows the profile path as RootCachePath + Default.There is this ominous warning in the official documentation for CachePath (https://cef-builds.spotifycdn.com/docs/129.0/structcef__settings__t.html#ad1644a7eb23cad969181db010f007710) that seems preserved in the CefSharp docs. I don't get what it is saying:
Any child directory value will be ignored and the "default" profile (also a child directory) will be used instead.At a minimum even if it is saying it completely ignores a proper set cachepath it would still imply that null should be incognito mode I believe.
One oddity is that using the same 129 binaries my more complex client is able to properly set the profile path in my request context handler. Clearly I should trace this to figure the difference from the official sample as to why it does work to change the cache path.
Expected behavior
setting cachepath to a proper immediate child of RootCachePath would have all profile data stored there.
Actual behavior
CachePath essentially seems ignored.
Regression?
yes
Known Workarounds
No response
Does this problem also occur in the CEF Sample Application
Yes using WPF/OffScreen command line args
Other information
in terms of cefclient.exe this is a bit hard to test. You can't set root_cache_path separate from cache_path. It does have
--request-context-per-browserwhich will append the timestamp as the subdir under the root cache path. This does create such a directory but it is completely empty. It is not an incognito window (at least shows profile selection). Cookies however are not shared like the CefSharp example behavior.Hitting alt + t for new tab opens a new window but this shares the cookie context with the first.
Going to tests-> New Window however does create a new context (and that subdir again is created but empty) but the cookie context is not shared with the new tab.
Full startup command like:
./cefclient.exe --no-sandbox --lang=en-US --remote-debugging-port=8088 --uncaught-exception-stack-size=10 --use-chrome-style-window --disable-features=EnableHangWatcher --disable-chrome-login-prompt --hide-crash-restore-bubble --enable-unsafe-extension-debugging --enable-experimental-extension-apis --no-proxy-server --cache-path=C:/RootCache --request-context-per-browser --url=https://google.com