Questions about the Browser process ProcessMessageReceived event

[sxmxta]

Hello, @salvadordf
I am the author of the energy open source framework, which is developed by Golang based on CEF4Delphi.

---

Recently, I encountered a problem in the browser process's ProcessMessageReceived event, where there was a minor issue when starting a thread.

At first, I thought this problem was caused by my encapsulation of the CEF4Delphi API.
Then I tested it. I also reproduced it when using the JSExtension case.

The cause of the matter,
I want to process asynchronous thread tasks in the ProcessMessageReceived event. That is, after receiving a message, I want to start a thread (in Go, it is a goroutine).
At this time, if I add a debug breakpoint in the IDE, the IDE will freeze and become unresponsive during step-by-step debugging, eventually leading to the IDE closing and preventing debugging.
Note: The IDE will not respond only when there is a breakpoint in debug.

---

The JSExtension example in Lazarus also reproduces this issue. The problem occurs when a debug breakpoint is set within a thread.

I am not sure whether it conflicts with the CEF's thread management model.

Do you have any good solutions? Or is the use of threads not permissible within this event?

---

thanks!

[salvadordf]

Hi,

I just tested the JSExtension demo with Lazarus 3.2 in Windows 10 (64 bits) and I can't reproduce this issue. I built the demo in 64 bits and I used "Dwarf 2 with sets".
I set a breakpoint here

The same demo also works fine in Delphi with a breakpoint in the same place.

That event is executed in a CEF thread and it shouldn't have any code that modifies Windows controls. However, I added a status bar update because it doesn't create or destroy controls.
Some demos break that rule to make the demos easier to understand but it's not recommended to modify controls outside the main application thread.

[salvadordf]

In general, it's better if the code in the CEF events is as simple as possible to avoid blocking any CEF thread.
Blocking the main application thread is not recommended either.

[sxmxta]

Okay, I'll send you an example of the key parts of this code

---

CEF4Delphi 118.7.1

demo: JSExtension

TMyThread = class(TThread)
protected
  procedure Execute; override;
end;

procedure TMyThread.Execute;
var
  i: integer;
begin
 // *Note: Debug and set breakpoints here
  for i := 0 to 100 do 
  begin
    Sleep(20); // Simulate time-consuming operations within threads
  end;
end;

procedure TJSExtensionFrm.Chromium1ProcessMessageReceived(Sender: TObject; const browser: ICefBrowser; const frame: ICefFrame;
  sourceProcess: TCefProcessId; const message: ICefProcessMessage; out Result: boolean);
var
  Thread1: TMyThread;
begin
  Result := False;

  if (message = nil) or (message.ArgumentList = nil) then exit;

  // This function receives the messages with the JavaScript results

  // Many of these events are received in different threads and the VCL
  // doesn't like to create and destroy components in different threads.

  // It's safer to store the results and send a message to the main thread to show them.

  // The message names are defined in the extension or in JS code.

  // For convenience, create a thread directly and start it
  Thread1 := TMyThread.Create(True
  Thread1.FreeOnTerminate := True;
  Thread1.Start;
  if (message.Name = MOUSEOVER_MESSAGE_NAME) then
  begin
    StatusPnl.Caption := message.ArgumentList.GetString(0); // this doesn't create/destroy components
    Result := True;
  end
  else
  if (message.Name = CUSTOMNAME_MESSAGE_NAME) then
  begin
    FText := message.ArgumentList.GetString(0);
    PostMessage(Handle, MINIBROWSER_SHOWTEXTVIEWER, 0, 0);
    Result := True;
  end;
end;

[sxmxta]

My Lazarus environment is the same as yours

You may need to test this process multiple times, repeating F8 or F9 within the thread
This result may be freezing Lazarus 3.2 IDE or the entire desktop explorer

[sxmxta]

This problem cannot be reproduced just by debugging a few times.

This problem doesn't recur every time, it may require repeated shutdown, startup, and debugging

[salvadordf]

I'm sorry but I added exactly the same code and I also put the same breakpoints but I still cannot reproduce this issue.
The IDE stopped in those breakpoints more than 50 times and I clicked F9 each time to keep executing the demo.
I used the latest CEF4Delphi version 123.0.13.

Instead of breakpoints try enabling the debug log and call CefDebugLog with the debug information you need. That function is available in uCEFMiscFunctions.

[sxmxta]

Alright, thank you.

The issue does not necessarily reproduce 100% of the time on my computer. However, it does indeed exist. It only occurs when breakpoints are set during the debugging process, leading to the entire IDE becoming unresponsive until it is automatically closed. I've asked around, and it's said that it's likely caused by breakpoints during the debugging process, resulting in a soft interrupt.