Create a ChromiumWebBrowser to render a small html (without javascript or much data and styles) from string as following:
using var browser = new ChromiumWebBrowser(new HtmlString(html));
Take a screenshot of the rendered page
await browser.WaitForInitialLoadAsync();
await browser.WaitForRenderIdleAsync(100, cancellationToken: ct);
await browser.CaptureScreenshotAsync(CaptureScreenshotFormat.Png); // this step is not really important; it's just for the context
Expected behavior
According to the documentation for CachePath setting:
If the value is empty then browsers will be created in "incognito mode" where in-memory caches are used for storage and no data is persisted to disk.
So we do not expect any changes on disk after we render html string.
Actual behavior
A directory with the name CEF is created under %USERPROFILE%\AppData\Local.
The file History in this directory starts to grow after each render. We looked inside the CEF history (through cef sample app) and found out that all our HTML pages are actually stored there. As a result, the file History grows up very quickly, up to several GB
After the History file reaches this size, the application tries to read all this data in memory and experiences performance problems on startup. It consumes a lot of memory and disk IO
Regression?
We did not experience any similar problems in versions 124.3.80 and earlier. It started from v125.0.210.
Known Workarounds
We haven't found any workarounds. But I guess if history contains rendered HTML, we should not use shared cache at all. So we are planning to create a separate RequestContext for each render:
using var browser = new ChromiumWebBrowser(new HtmlString(html), requestContext: new RequestContext(new RequestContextSettings
{
CachePath = null,
PersistSessionCookies = false,
PersistUserPreferences = false
}));
By the way, the file History in AppData/Local/CEF doesn't grow this way. I assume in this case the cache is actually stored in memory.
Does this problem also occur in the CEF Sample Application
Not Tested
Other information
I'm not really sure it is a bug, but the growth of the History file on disk was kind of unexpected. It caused problems for us only because we render pages from HTML strings, so the browser history contains a lot of data. Probably it would not affect other CefSharp users as much.
Is there an existing issue for this?
CefSharp Version
127.3.50
Operating System
Windows 10
Architecture
x64
.Net Version
.net 8
Implementation
OffScreen
Reproduction Steps
Expected behavior
According to the documentation for
CachePath
setting:If the value is empty then browsers will be created in "incognito mode" where in-memory caches are used for storage and no data is persisted to disk.
So we do not expect any changes on disk after we render html string.Actual behavior
CEF
is created under%USERPROFILE%\AppData\Local
.History
in this directory starts to grow after each render. We looked inside the CEF history (through cef sample app) and found out that all our HTML pages are actually stored there. As a result, the fileHistory
grows up very quickly, up to several GBHistory
file reaches this size, the application tries to read all this data in memory and experiences performance problems on startup. It consumes a lot of memory and disk IORegression?
We did not experience any similar problems in versions 124.3.80 and earlier. It started from v125.0.210.
Known Workarounds
We haven't found any workarounds. But I guess if history contains rendered HTML, we should not use shared cache at all. So we are planning to create a separate
RequestContext
for each render:By the way, the file
History
inAppData/Local/CEF
doesn't grow this way. I assume in this case the cache is actually stored in memory.Does this problem also occur in the CEF Sample Application
Not Tested
Other information
I'm not really sure it is a bug, but the growth of the
History
file on disk was kind of unexpected. It caused problems for us only because we render pages from HTML strings, so the browser history contains a lot of data. Probably it would not affect other CefSharp users as much.