Support process singleton with IBrowserProcessHandler.OnAlreadyRunningAppRelaunch callback

[Mik4sa]

Is there an existing issue for this?

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

CefSharp Version

120.1.110

Operating System

Windows 11

Architecture

x64

.Net Version

.NET 4.7.2

Implementation

WinForms

Reproduction Steps

Reproducible with CefSharp.MinimalExample since 120.1.110 (cefsharp/CefSharp.MinimalExample@136a65e).
Just launch the application twice.

Expected behavior

A second launch of the application should be possible (without any restrictions).

Actual behavior

A launch of any more instances result in a crash.

This is the output of thedebug.log from the second launch:

[0109/101550.274:ERROR:crashpad_client_win.cc(546)] CreateProcess: Das System kann die angegebene Datei nicht finden. (0x2)
[0109/101550.285:INFO:crash_reporting.cc(216)] Crash reporting enabled for process: browser
[0109/101550.289:WARNING:alloy_browser_main.cc(167)] Unhandled app relaunch; implement CefBrowserProcessHandler::OnAlreadyRunningAppRelaunch.
[0109/101550.289:ERROR:crashpad_client_win.cc(143)] crash server failed to launch, self-terminating

Regression?

This was working with v120.1.80.

Known Workarounds

No known workarounds

Does this problem also occur in the CEF Sample Application

No

Other information

No response

[yngwu]

Same here in our WPF application. Debug.log from v120.1.110

0110/102929.043:WARNING:alloy_browser_main.cc(167)] Unhandled app relaunch; implement CefBrowserProcessHandler::OnAlreadyRunningAppRelaunch.
[0110/103024.131:WARNING:alloy_browser_main.cc(167)] Unhandled app relaunch; implement CefBrowserProcessHandler::OnAlreadyRunningAppRelaunch.
[0110/103203.453:WARNING:alloy_browser_main.cc(167)] Unhandled app relaunch; implement CefBrowserProcessHandler::OnAlreadyRunningAppRelaunch

Looks like it's related to the process singleton enabled by default and a virtual function CefBrowserProcessHandler::OnAlreadyRunningAppRelaunch need to be implemented, see chromiumembedded/cef#3615.

https://github.com/chromiumembedded/cef/blob/a097b62b6e048613484e23ca038c4f1b1dd22cd5/libcef/browser/alloy/alloy_browser_main.cc#L167

[amaitland]

Chromium is designed so only a single process can access a Cache at a time. Multiple processes is not supported. If it worked previously then it was by luck, not design.

This was working with v120.1.80.

The only CefSharp change was to upgrade to a newer CEF version. You can easily compare tags on github v120.1.80...v120.1.110

Reproducible with CefSharp.MinimalExample since 120.1.110 (cefsharp/CefSharp.MinimalExample@136a65e).
Just launch the application twice.

The MinimalExample isn't designed to be run multiple times. It has a fixed CachePath.

A second launch of the application should be possible (without any restrictions).

That's not really something CefSharp has control over. Someone should ask on chromiumembedded/cef#3615 to see if the change in behaviour is expected.

[0109/101550.289:WARNING:alloy_browser_main.cc(167)] Unhandled app relaunch; implement CefBrowserProcessHandler::OnAlreadyRunningAppRelaunch.

We need to add IBrowserProcessHandler.OnAlreadyRunningAppRelaunch we can use this issue to track that work.

[amaitland]

///
/// Implement this method to provide app-specific behavior when an already
/// running app is relaunched with the same CefSettings.root_cache_path value.
/// For example, activate an existing app window or create a new app window.
/// |command_line| will be read-only. Do not keep a reference to
/// |command_line| outside of this method. Return true if the relaunch is
/// handled or false for default relaunch behavior. Default behavior will
/// create a new default styled Chrome window.
///
/// To avoid cache corruption only a single app instance is allowed to run for
/// a given CefSettings.root_cache_path value. On relaunch the app checks a
/// process singleton lock and then forwards the new launch arguments to the
/// already running app process before exiting early. Client apps should
/// therefore check the CefInitialize() return value for early exit before
/// proceeding.
///
/// This method will be called on the browser process UI thread.
///
/*--cef(optional_param=current_directory)--*/
virtual bool OnAlreadyRunningAppRelaunch(
    CefRefPtr<CefCommandLine> command_line,
    const CefString& current_directory) {
  return false;
}

On relaunch the app checks a process singleton lock and then forwards the new launch arguments to the
already running app process before exiting early. Client apps should therefore check the CefInitialize() return value for early exit before proceeding.

As per CEF API doc (from above).

[Mik4sa]

Ok, got it, thanks
Afaik in our main application we do not have a CachePath set (so no cache is written to the disk) and still the application is crashing. Maybe this info is relevant to you too.

[amaitland]

[0109/101550.289:WARNING:alloy_browser_main.cc(167)] Unhandled app relaunch; implement CefBrowserProcessHandler::OnAlreadyRunningAppRelaunch.

CEF thinks your application has relaunched with a CachePath or RootCachePath identical to another process. RequestContext cache paths would also count.

Afaik in our main application we do not have a CachePath set (so no cache is written to the disk) and still the application is crashing. Maybe this info is relevant to you too.

Load chrome://version in a ChromiumWebBrowser instance within your application to see what CEF thinks your path values are.

Again from a CefSharp point of view the only thing that changed was an upgrade to a newer version of CEF.

If your application doesn't have a cache set then you'll need to raise an issue at https://github.com/chromiumembedded/cef/issues as that would be an upstream bug.

[Mik4sa]

Ok I see. There is always a root cache path:

[Mik4sa]

@amaitland Is there a function to get the default root cache path?
Or a way to call native functions from them? Like GetDefaultUserDataDirectory? See: https://source.chromium.org/chromium/chromium/src/+/main:chrome/common/chrome_paths_internal.h?q=GetDefaultUserDataDirectory&ss=chromium

[amaitland]

Client apps should therefore check the CefInitialize() return value for early exit beforeproceeding.

If the second process call to Cef.Initialzie() isn't returning a value (if it's crashing or terminating the process), then someone needs to create an issue at https://github.com/chromiumembedded/cef/issues