ExternalPumpBrowser Lazarus demo crashes after navigation in macOS 15.1.1 on an M4 CPU.
sxmxta opened this issue · 9 comments
Hello,
When I was doing the encapsulation of the energy framework on MacOS M4 and conducting tests, I found that in the TCefApplicationCore.LoadCEFlibrary function, the loading of the CEF library failed during the startup initialization. The value returned by FLibHandle := LoadLibrary(LibCefPath); is 0.
System environment:
MacOS ARM64
Version: 15.1.1
Sample program: ExternalPumpBrowser
No errors were found on MacOS Intel x86, M1, and lower-version M2 systems.
In addition, there are other issues.
I encapsulated CEF4Delphi as a dynamic link library. Since the return value of loading the lib library is 0, I pre-loaded the CEF Lib library in the calling language of the library and then passed the handle to FLibHandle through the API.
In this way, the APIs related to initializing the CEF lib can be initialized normally. However, there are some problems. After running, when opening certain websites or right-clicking on the program, it will crash.
I don't have a mac computer and I can't test CEF4Delphi. Read about the notarization requirements in newer macOS versions.
If you initialize CEF inside a DLL then the browsers must be created in the DLL's code too. See the DLLBrowser demo.
hello
Maybe there's something wrong with the way I said it.
Let me rephrase the problem.
Let's start with the simplest.
CEF 130.1.16
System: MacOS 15.1
demo: ExternalPumpBrowser
IDE: Lazarus 3.6
Problem: When the program is started, the Chromium Embedded Framework returns 0
The ExternalPumpBrowser example works fine on MacOS 12
I just received a confirmation that CEF4Delphi works fine in macOS 15.1 for x86.
The """closest""" (notice the quotes) thing I can personally test is a RaspberryPi 5 with an arm64 processor and it also works fine.
I can only suggest that you enable the debug log and also read the GlobalCEFApp.LastErrorMessage value. Post the log and the GlobalCEFApp.LastErrorMessage value here.
Try running the official CEF sample application on MacOS 15.1 in a M4 processor.
https://cef-builds.spotifycdn.com/cef_binary_131.2.7%2Bg9a14dc9%2Bchromium-131.0.6778.86_macosarm64_client.tar.bz2
Okay, thank you,
The cefclient example works properly.
CEF4Delphi It does not work properly in a lazarus environment. Which is the problem I described above
In the environment of macOS 15.1.1 and Lazarus 3.6, I've discovered several problems:
- When loading the CEF Lib, it returns 0.
- The timing for initializing the objective-c NSApp in the AddCrDelegate function is incorrect. It is required to execute "TCrCocoaApplication.sharedApplication;" in advance.
- After the page is displayed, the program crashes when switching the input method. Moreover, the program crashes when loading some pages.
Explanation:
Problem 2:
app.SetMultiThreadedMessageLoop(false)
app.SetExternalMessagePump(false)
Resolved:
procedure AddCrDelegate;
var
delegate: id;
begin
// CEF要求在创建NSApp之前,必须先实例化 TCrCocoaApplication
// 否则CEF获取不到 isHandlingSendEvent
TCrCocoaApplication.sharedApplication;
delegate := TChromeAppDelegateIntercept.alloc.initWithDelegate(NSApp.delegate);
NSApp.setDelegate(delegate);
end;
Problem 3:
app.SetExternalMessagePump(true)
app.SetMultiThreadedMessageLoop(false)
I just updated CEF4Delphi with a possible fix for this issue.
Please, download CEF4Delphi again and test demos\Lazarus_Mac\ExternalPumpBrowser in macOS 15.1 with the M4 CPU.
Apparently, the render processes require some extra entitlements :
<key>com.apple.security.cs.allow-jit</key> <true/> <key>com.apple.security.cs.allow-unsigned-executable-memory</key> <true/> <key>com.apple.security.cs.disable-library-validation</key> <true/>
https://magpcss.org/ceforum/viewtopic.php?f=6&t=20345#p57803
I added them to the Delphi demo but I can't test this.
Okay, I have time to test this. I noticed that this issue started existing in CEF 128, while versions 127 and below do not have this problem.


