request context cache path issues

[mitchcapper]

Is there an existing issue for this?

• I have searched both open/closed issues, no issue already exists.

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-browser which 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

[amaitland]

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]

https://www.magpcss.org/ceforum/viewtopic.php?f=6&t=19891 might be one of those.