Questions about the Browser process ProcessMessageReceived event about cef4delphi HOT 7 CLOSED

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.

from cef4delphi.

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.

from cef4delphi.

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;

from cef4delphi.

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

from cef4delphi.

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

from cef4delphi.

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.

from cef4delphi.

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.

from cef4delphi.