Skip to content

Expose Chromium SurfaceEmbed for embedding browser content within a host page #4321

Open

Description

@nyssance

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

  1. magreenblatt commented on Oct 21, 2026

    @magreenblatt
    Collaborator

    If I understand correctly, the proposed flow would be: create browser → obtain token → insert <embed> with token.

    Beyond the token, CEF would need:

    • Plugin integration: Enable SurfaceEmbed’s renderer plugin and browser-side interface for application pages.
    • Authorization: Let the application control which host frames can embed guests.
    • Browser hosting: Support a guest without its own native window or OSR view—possibly through a new creation mode.
    • Lifecycle integration: Make detach, reattach, navigation, crashes, and closing work with CEF ownership and callbacks.
    • Platform validation: Verify focus, input, accessibility, menus, dialogs, and popups.

    This represents a significant development effort.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions