RDEV-8412 - Bump to CEF v134.3.9

[heldergoncalves92]

Description

GPU issues from CEF M121) ✔️

Found a solution here.

---

macOS vulkan issues ✔️

This issue seems related with that Avalonia Sample App.
The fix was to start to use Avalonia ReactiveUI framework.

/Users/hgo/CefGlue/CefGlue.Demo.Avalonia/bin/ARM64/Debug_WindowlessRender/net8.0/Xilium.CefGlue.Demo.Avalonia
objc[39249]: Class ExtensionDropdownHandler is implemented in both /Users/hgo/CefGlue/CefGlue.Demo.Avalonia/bin/ARM64/Debug_WindowlessRender/net8.0/runtimes/osx/native/libAvaloniaNative.dylib (0x1237760e0) and /Users/hgo/CefGlue/CefGlue.Demo.Avalonia/bin/ARM64/Debug_WindowlessRender/net8.0/libcef.dylib (0x33f1ce3b0). One of the two will be used. Which one is undefined.
2025-04-15 20:18:33.884 Xilium.CefGlue.Demo.Avalonia[39249:997598] +[IMKClient subclass]: chose IMKClient_Modern
2025-04-15 20:18:33.884 Xilium.CefGlue.Demo.Avalonia[39249:997598] +[IMKInputSession subclass]: chose IMKInputSession_Modern
[39304:259:0415/201834.846656:ERROR:angle_platform_impl.cc(49)] vk_renderer.cpp:184 (VerifyExtensionsPresent): Extension not supported: VK_EXT_metal_surface
[39304:259:0415/201834.846891:ERROR:angle_platform_impl.cc(49)] vk_renderer.cpp:184 (VerifyExtensionsPresent): Extension not supported: VK_KHR_surface
[39304:259:0415/201834.846918:ERROR:angle_platform_impl.cc(49)] Display.cpp:1085 (initialize): ANGLE Display::initialize error 0: Internal Vulkan error (-7): A requested extension is not supported, in ../../third_party/angle/src/libANGLE/renderer/vulkan/vk_renderer.cpp, enableInstanceExtensions:2144.
[39304:259:0415/201834.846942:ERROR:gl_display.cc(495)] EGL Driver message (Critical) eglInitialize: Internal Vulkan error (-7): A requested extension is not supported, in ../../third_party/angle/src/libANGLE/renderer/vulkan/vk_renderer.cpp, enableInstanceExtensions:2144.
[39304:259:0415/201834.847043:ERROR:gl_display.cc(767)] eglInitialize SwANGLE failed with error EGL_NOT_INITIALIZED
[39304:259:0415/201834.847057:ERROR:gl_display.cc(802)] Initialization of all EGL display types failed.
[39304:259:0415/201834.847076:ERROR:gl_initializer_mac.cc(125)] GLDisplayEGL::Initialize failed.

---

Remove Alloy Runtime (Removed on CEF M128) ❌

Following: chromiumembedded/cef#3685
However, there are still issues directly related to this. Have the bellow crash. Still trying to figure it out.

ERROR:network_service_instance_impl.cc(600)] Network service crashed, restarting service.

Found this post, reporting the same symptom.
Could replicate this issue by shifting to Chrome Runtime. Was able to replicate the issue in CEF M126

---

Upgrading to CEF M133: ✔️
Follow the main guidelines from this (link)

Current State Window

• Build ✅
• Runtime ❌
• Dev Tools ❌
• WebGL (test here) (Possible related issue) ❌
• Automatic Tests ❌

Current State macOS ✅

• Build ✅
• Runtime ✅
• Dev Tools ✅
• WebGL (test here) ✅

[heldergoncalves92]

This may be relevant

[cssecautomation]

🎉 Snyk checks have passed. No issues have been found so far.

✅ security/snyk check is complete. No issues have been found. (View Details)

✅ license/snyk check is complete. No issues have been found. (View Details)

✅ code/snyk check is complete. No issues have been found. (View Details)

[filipnavara]

The crash you see on Windows is not actually related to the network service. The problem is that the .pak files are not copied to the locales folder in the demo application. You can manually copy them there from CefGlue\packages\chromiumembeddedframework.runtime\134.3.9\CEF\win-x64\locales\ to check that it works. The build steps will need to be fixed to do it automatically.

In case you are wondering how to debug this issue, here is what I did:

• Install WinDBG (either as part of Visual Studio or Windows SDK)
• Run the WinDBG and set it as post-mortem debugger in Windows (button in the Settings dialog)
• Download the CEF release symbols for a given version and extract them next to libcef.dll in the app output folder
• Run the demo app
• When the child process crashes, it will automatically lauch WinDBG and it shows you the stack trace in CEF/Chromium code.
• Check the code to see if there's an obvious cause.

Hope this helps!

[filipnavara]

The minimal fix is

--- a/CefGlue.Common/build/CefGlue.Common.targets
+++ b/CefGlue.Common/build/CefGlue.Common.targets
@@ -73,10 +73,11 @@
      Relies on ResolvePackageAssets MSBuild target to identify resources deployed from that specific package. -->
     <Target Name="ResolveCEFAssets" Condition="$([MSBuild]::IsOSPlatform('Windows')) and '$(CefGlueTargetPlatform)' != ''" AfterTargets="ResolvePackageAssets">
         <ItemGroup Condition="'$(CefGlueTargetPlatform)' == 'win-x64' OR '$(CefGlueTargetPlatform)' == 'win-arm64'">
-            <CefRuntimeFiles Include="@(RuntimeTargetsCopyLocalItems->WithMetadataValue('NuGetPackageId', 'chromiumembeddedframework.runtime.$(CefGlueTargetPlatform)'))" />
+            <CefRuntimeFiles Include="@(CefRedist64)" Condition="'$(CefGlueTargetPlatform)' == 'win-x64'" />
+            <CefRuntimeFiles Include="@(CefRedistArm64)" Condition="'$(CefGlueTargetPlatform)' == 'win-arm64'" />
             <None Include="@(CefRuntimeFiles)">
                 <Visible>false</Visible>
-                <Link>$(OutputDirectory)%(FileName)%(Extension)</Link>
+                <Link>$(OutputDirectory)%(RecursiveDir)%(FileName)%(Extension)</Link>
                 <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
                 <CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
                 <PublishState>Included</PublishState>

[cyraid]

I'm thinking of "gluing" CEFGlue into my project, and wondering how it's coming with the upgrading to a recent version of CEF?