CEF + --no-proxy-server switch

[Santiago Aguiar]

We are having some crashes with CEF and IE, and we suspect it might be related to the presence of proxy servers, though we don't have a confirmation yet. 

There's a bug related to that (https://code.google.com/p/chromiumembedded/issues/detail?id=927), which can supposedly be avoided by passing the "--no-proxy-server" switch to CEF.

We are running the following initialization code:

            CefRuntime.Load();

            var codeBase = Path.GetDirectoryName(new Uri(Assembly.GetEntryAssembly().CodeBase).LocalPath);

            var settings = new CefSettings

            {

                Locale = "en-US", // Always use the en-US locale to avoid having to pack additional locales.

                CachePath = null, // Use an in-memory cache.

                MultiThreadedMessageLoop = true,                         

                LocalesDirPath = codeBase, // en-US.pak is included on the same folder as the binaries.

                BrowserSubprocessPath = Path.Combine(codeBase ?? string.Empty, RenderSubProcessPathBinary),

                SingleProcess = false,                

                ReleaseDCheckEnabled = false,

                LogSeverity = CefLogSeverity.Disable,                

            };

            var app = new BrowserApp(_startUrl);

            var args = new CefMainArgs(new[] { "--no-proxy-server" });

            

            var exitCode = CefRuntime.ExecuteProcess(args, app);

            if (exitCode != -1)            

                throw new InvalidOperationException("Unable to execute CEF.");            

            CefRuntime.Initialize(args, settings, app); 

However, when running with verbose log severity, we get the following lines:

[0813/120731:VERBOSE1:pref_proxy_config_tracker_impl.cc(145)] 074B1B40: set chrome proxy config service to 074B15A0

[0813/120731:VERBOSE1:pref_proxy_config_tracker_impl.cc(235)] 074B1B40: Done pushing proxy to UpdateProxyConfig

Which I guess means that CEF is trying to do _something_ with proxies ;). Do we need to pass the --no-proxy-server switch in some other place? Maybe OnBeforeChildProcessLaunch, or in the OnBeforeCommandLineProcessing of the Render process?

Thanks!

[Santiago Aguiar]

OK, it seems CefMainArgs are ignored on Windows (sigh! :)), so I had to declare the switch on the OnBeforeChildProcessLaunch on the browser process CefApp. The verbose messages are still there, but we had no more issues with proxies.

--
You received this message because you are subscribed to the Google Groups "CefGlue" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cefglue+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Mitchell Boulter]

I've had the same issue in a project I am working on.

The solution that's worked for me for the time being is to set;

        cefSettings.SingleProcess = false;

        cefSettings.MultiThreadedMessageLoop = false;

and run my own message loop instead;

        public static void MessageLoop()

        {

            var win = new BrowserWindow();

            win.Closed += (o, a) => CefRuntime.QuitMessageLoop();

            win.Show();

            CefRuntime.RunMessageLoop();

        }

For some reason, the issue only seems to crop up when you're running with a MultiThreadedMessageLoop AND the multiple process implementation.

[Santiago Aguiar]

We wanted to use multi process implementation since it's the 'supported' configuration for release builds, and the problem went away once we added the --no-proxy-server switch in the right place (OnBeforeChildProcessLaunch on the browser process CefApp).

My only regret was that we were cautious enough to add the switch before releasing, since we checked the open crash bugs, but I never actually tested it was preventing the bug ;). Maybe CEF should blow up if passing a non-empty CegMain args in windows, since apparently they will be ignored anyway :).

[Dmitry Azaraev]

@Mitchell - It is not intuitive, but, you are correct. Whenever is possible - is better use single threaded message loop. mtmp implementation can cause some issues. Some issues are fixed in newer builds.

--
You received this message because you are subscribed to the Google Groups "CefGlue" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cefglue+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Best regards,
   Dmitry