Repository navigation
Description
Is your feature request related to a problem? Please describe.
CEF applications with a web-based UI need to embed independent browser pages within that UI, while allowing host HTML dialogs and menus to appear over the live page and keeping clipping/resizing synchronized with DOM layout. Native child browser views do not participate in the host document's DOM stacking. Implementing a separate OSR compositor also requires additional rendering and input integration.
Describe the solution you'd like
Please consider exposing Chromium's SurfaceEmbed through supported CEF APIs. Its integration guide describes browser-side interface registration, renderer-side plugin creation, and a content handle used by an <embed> element.
The desired scope is:
- Enable embedding for explicitly trusted host frames/origins, without exposing privileged bindings to arbitrary guest pages.
- Obtain an opaque embedding handle for a CEF-managed browser and attach its surface to an element in the host page.
- Define ownership, detach/re-attach, navigation and close semantics compatible with CEF's browser lifecycle.
- Expose the API through CEF's C API so bindings such as cef-rs can use it with binary distributions.
Would an API proposal for this integration be acceptable, and which runtime style would be appropriate? This requests SurfaceEmbed integration rather than the full Chrome Apps <webview> API discussed in #3038.
Describe alternatives you've considered
- Ordinary iframes: constrained by sites' framing policies and do not provide the same browser-instance control.
- Native child views: unsuitable for host HTML stacking and clipping requirements.
- OSR: useful for custom renderers, but does not itself attach a guest surface to the host DOM compositor.
Additional context
Environment inspected: CEF 154.0.34+g14c5a08+chromium-154.0.8037.98, macOS 27.0.1 ARM64, cef-rs 154.5.0+154.0.34, Tauri runtime-cef 3.0.0-alpha.6; Rust 1.99.1 and Apple Clang 21.0.0. CEF was a precompiled distribution, not a local C++ build.
A minimal runtime probe confirmed that an ordinary <webview> in the application page did not instantiate a guest. Enabling SurfaceEmbed alone did not expose host bindings. No native guest handle was supplied, so this is not a failed SurfaceEmbed attachment test or evidence that Chromium's implementation is broken. The missing piece being requested is supported CEF integration.
Assisted-by: OpenAI Codex
Activity
magreenblatt commentedon Oct 21, 2026
If I understand correctly, the proposed flow would be: create browser → obtain token → insert
<embed>with token.Beyond the token, CEF would need:
This represents a significant development effort.