Repository navigation
Page hit-testing doesn't work as expected when external_begin_frame_enabled is true and SendExternalBeginFrame() is used #4355
Description
Using CEF 156.0.14 Windows 64 and macOS.
My OSR app has CefWindowInfo::external_begin_frame_enabled = true and I send SendExternalBeginFrame() explicitly from my apps message loop on a regular basis.
On pages with their own internal hit-testing/gesture logic over a (I've been using https://maps.google.com and clicking/hovering a POI marker), clicks and hover-highlighting never register so the page interactions appear broken.
In a JS dev console opened on that page, I see that document.elementFromPoint(x, y) at the click coordinates resolves to a background <div> instead of the page's own WebGL <canvas> - like I see in Desktop Chrome.
Turning off CefWindowInfo::external_begin_frame_enabled results in everything working as expected.
I wasn't able to try it in cefclient - I don't know how to mirror the settings my app is using.
Is this a bug or do I need to modify my code?
Activity
magreenblatt commentedon Nov 10, 2026
In cefclient run with
--off-screen-rendering-enabled --external-begin-frame-enabled. This works for me on macOS 27.2 at M158 using a touch pad. If the issue still reproduces for you in cefclient at this version please provide additional reproduction details.callumlinden commentedon Nov 10, 2026
Thankfully that does work in cefclient (v156 Win/Mac) with those command line options in place which means it's my code.
Apart from the page interaction breaking (POIs do not highlight on mouseover or activate on click), printing the element under the mouse cursor on mousemove reports something entirely different from Desktop Chrome.
This is a complete rewrite and my code has grown quite large and complex so determining which other calls I am making that are responsible will be a challenge. I'll see if I can distill a subset out to something much more simple.
callumlinden commentedon Nov 11, 2026
I broke out the code into a separate, small application and with
CefWindowInfo::external_begin_frame_enabledset to true I still saw the problem I described for sites like Google Maps. After looking at what cefclient does, I replaced the call in my message loop toSendExternalBeginFrame()with aCefPostDelayedTask(TID_UI, ...)loop, also drivingSendExternalBeginFrame(). No change in behavior. I imagine some setting or command line option I have in place is causing the disparity - I'll look at that tomorrow.If I set
CefWindowInfo::external_begin_frame_enabledtofalseand usedCefBrowserHost::Invalidate(PET_VIEW)to force repaints, the issue goes way although interactivity felt a bit more sluggish compared to when I usedSendExternalBeginFrame()- maybe that's expected.However, it's not possible for me to use that approach because there are many active instances (up to 32) and there is a scheduler to smoothly adjust the update rate of each browser based on visibility, distance from the camera etc. The
SendExternalBeginFrame()paradig​m worked well for this and I can't find an alternative that works. Updatingwindowless_frame_ratefor each browser after creation seems to not do what I need.