TTMSFNCEdgeWebBrowser - cache folder - critical error

FNC TMS FNC Core
1

Hi,
**
TMSFNCEdgeWebBrowser1.CacheFolderName doesn't work. This freezes two instances of the program.**

How can I change TMSFNCEdgeWebBrowser1.CacheFolderName during Create, Show, DoShow / application startup?

not work:

procedure TForm6.FormCreate(Sender: TObject);
procedure TForm6.FormShow(Sender: TObject);
procedure TForm6.DoShow;
begin
TMSFNCEdgeWebBrowser1.CacheFolderName := FormatDateTime('hhnnss',time);
edit1.text := TMSFNCEdgeWebBrowser1.GetUserDataFolder;
end;

image
image552×491 14.4 KB

**This is a serious problem because when two instances of the same application are running, an action performed on one instance causes the other instance to hang.

(click "Click to FREEZE button, when two instances running)**

However, this works:

procedure TForm6.Button2Click(Sender: TObject);
begin
// it work, BUT I wouldlike have the same in CreateForm
TMSFNCEdgeWebBrowser1.DeInitialize;
ExtractFilePath(ParamStr(0))+FormatDateTime('hhnnss',time)+'';
TMSFNCEdgeWebBrowser1.CacheFolderName := FormatDateTime('hhnnss',time);
TMSFNCEdgeWebBrowser1.Initialize;
edit1.text := TMSFNCEdgeWebBrowser1.GetUserDataFolder;
end;

all is OK

image
image592×517 14.4 KB

So, if I call DeInitialize, change CacheFolderName, and then call Initialize, everything works correctly.

I would like to achieve the same result during form creation/application startup, without having to do it later from a button click.

I tested the standard TEdgeBrowser, and it works correctly in this scenario.

The same problem also occurs with TMS FNC Maps VCL.

Could you please advise when and how CacheFolderName should be set so that each application instance uses its own user data/cache folder?

It is critical Error.

TMS_webbrowser_error.zip (93.8 KB)

2

I'm heave the same problem

TMSFNCEdgeWebBrowser1.CacheFolder := ExtractFilePath(ParamStr(0));
"D:\TESTAPP\Project6"

TMSFNCEdgeWebBrowser1.CacheFolderName := FormatDateTime('hhnnss',time);
"211221"
edit1.text := TMSFNCEdgeWebBrowser1.GetUserDataFolder;
'C:\Users\arekw\AppData\Local\Temp\Project6\EdgeCache'

Why?
TTMSFNCWinWebBrowser.UpdateCacheFolderName set FFullCacheFolderName = "D:\TESTAPP\Project6\211221"

and not send FFullCacheFolderName to browser

only TTMSFNCWinWebBrowser.Initialize invoke

if (pth <> '') and DirectoryExists(pth) then
h := CreateCoreWebView2EnvironmentWithOptions(PWideChar({$IFDEF LCLLIB}UTF8Decode{$ENDIF}(pth)), PWideChar({$IFDEF LCLLIB}UTF8Decode{$ENDIF}(FFullCacheFolderName)), envOpt, TCoreWebView2CreateCoreWebView2EnvironmentCompletedHandler.Create(Self))
else
h := CreateCoreWebView2EnvironmentWithOptions(nil, PWideChar({$IFDEF LCLLIB}UTF8Decode{$ENDIF}(FFullCacheFolderName)), envOpt, TCoreWebView2CreateCoreWebView2EnvironmentCompletedHandler.Create(Self));

3

I have confirmed the issue reported by another user. Despite this, it appears that no one has taken any interest in investigating it.

This report has been sitting unresolved for several days, and there has been no indication whatsoever that anyone on your team has even reviewed it.

Do you intend to fix this bug? Its severity makes it impossible for us to continue using your components. I expect a clear response and a specific plan and timeline for resolving this issue.

4

Hi,

I’m currently out of office (Holidays). I’m back on Friday and i’ll handle everything with highest priority. Hoping for your understanding.

5

Thank you for the detailed report — this is very helpful, and the behavior you're seeing is expected given how the component initializes. Here's what's going on and the recommended way to solve it.

Why setting CacheFolderName in FormCreate/FormShow has no effect

The Edge (WebView2) environment is created automatically and early in the control's lifecycle — during DFM streaming (Loaded) and when the window handle is allocated (CreateWnd). Both of these run before your OnCreate and OnShow handlers. So by the time your code assigns CacheFolderName, the WebView2 environment already exists and is bound to the default folder. Your assignment only updates an internal string; it does not recreate the already-running environment.

The default folder is derived from the executable name:

%TEMP%\<exename>\EdgeCache

Because it's based on the exe name, two instances of the same application end up using the identical user-data folder, and the two WebView2 processes collide — which is the freeze you are observing.

Your button works precisely because DeInitialize destroys the existing environment first, and Initialize then recreates it against the new folder.

Recommended solution

Do exactly what your button does, but at startup. Two important details:

  1. Use a value that is genuinely unique per instance. FormatDateTime('hhnnss', Time) is not sufficient — two instances launched in the same second get the same name and still collide. Use the process ID (or a GUID).
  2. The environment is created asynchronously, so GetUserDataFolder returns an empty string immediately after Initialize. Read it in the OnInitialized event instead.
uses Winapi.Windows;

procedure TForm6.FormCreate(Sender: TObject);
begin
  TMSFNCEdgeWebBrowser1.DeInitialize;
  TMSFNCEdgeWebBrowser1.CacheFolderName :=
    'Instance_' + IntToStr(GetCurrentProcessId);
  TMSFNCEdgeWebBrowser1.Initialize;
end;

procedure TForm6.TMSFNCEdgeWebBrowser1Initialized(Sender: TObject);
begin
  // Environment is ready here — this returns the real path
  Edit1.Text := TMSFNCEdgeWebBrowser1.GetUserDataFolder;
end;

With a unique folder per instance, the two applications no longer share a user-data folder and the freeze disappears. AutoClearCache (default True) will also correctly clean up each instance's own folder on shutdown.

Regarding the difference with TEdgeBrowser

The standard TEdgeBrowser does not create its environment during streaming — you call CreateWebView yourself after setting UserDataFolder, so there is no early environment to invalidate. The FNC control initializes eagerly, which is why the explicit DeInitialize → set CacheFolderName → Initialize step is needed.

TMS FNC Maps VCL

It uses the same underlying web browser control, so the same pattern applies there as well.

We'll also look into adding an option to defer the automatic initialization, so that CacheFolderName can be assigned before the first init without the DeInitialize/Initialize sequence.

6

What you're describing doesn't work.

Have you tested this in my TestApp? Because your solution isn't working for me. I'm attaching the project after your change.

The problem is that this doesn't work in onCreate.

Furthermore, performing DeInitialize in onCreate is a workaround.

In my opinion, this is a bug and the initialization issues need to be fixed once and for all, as this issue comes up from time to time.

Please analyze this report thoroughly. The problem is critical.

Project6.zip (79.2 KB)

7

We tested the app and indeed could see, when the application froze, the other application froze as well with the same cache folder. The workaround changing the cache folder during a from create will only work in certain circumstances, for example when programmatically creating the browser, or when no initialization has happened yet. It's indeed correct that the workaround in this case doesn't provide sufficient coverage of the problem, and a button click does. Aside from the additional property to avoid automatic initialization, and let you set the cache folder in the form create, we have implemented an additional check for multiple instances of the same application, so they don't write to the same cache folder. Next version of TMS FNC Core will have all improvements included.

8

Great information and great work! Can I request a HOTFIX? Unfortunately, this is very urgent for me and is blocking implementation work.

9

We are uploading the new version as we speak. v4.3.1.3 should have this fix included.