Skip to content

Issues with CEF3

Jump to bottom Edit New page
cmarcelo edited this page May 13, 2013 · 8 revisions

A prototype for Cameo was built using CEF3 for understanding better the issues. See Cameo prototype based on CEF3.

CEF3 Public API

  • Both C and C++ API is provided. Lots of stuff code is to help API conversion between C and C++. Its downside is to make code bloat if C API is not our scope.

  • Several Handler interfaces are provided for a high level abstraction. It is a good reference for cameo API design.

    • LifeSpanHandler - Hook into the lifetime of browser window, e.g. OnBeforeClose, DoClose etc.
    • DisplayHandler - Handle the events related to browser window state, e.g. address and title change.
    • V8Handler - Handle v8 native function calls.
    • RequestHandler - Handle event related to browser request
    • ResourceBundleHandler - Handle resource loading related stuff
    • GeolocationHandler - Handle events related to geolocation permission request.
    • ContextMenuHandler - Handle context menu in web page.
    • BrowserProcessHandler - Handle the events of browser process.
    • RenderProcessHandler - Handle the events of render process.
    • JSDialogHandler - Handle the events of Javascript dialogs, e.g. alert, prompt, and onbeforeunload.

  • A self-contained library and can be used separately outside of Chromium codebase. It defines some basic types, e.g. CefRefPtr, CefRefCounted, CefString etc, for this purpose.

Pain of writing WebView-like based on CEF3 API

  • Process main entry issue

Update: This is not an issue anymore. There's a configuration flag in CefSettings to provide a different separate executable for the extra processes.

The issue arises from the chromium multi-process architecture in which all processes code are bundled into one binary. As a result, the main entry of an application which uses WebView will be executed multiple times with different arguments for launching browser/renderer processes, therefore, the application MUST know the current process type in main function, otherwise, it will get error, e.g. it can’t execute any UI logic related code in renderer process. It is a tricky thing and not developer friendly.

The content switches --browser-subprocess-path may resolve this issue if we build a separate executable binary upon CEF3 API.

  • Toolkit Binding on Windows

On Windows, WebView just exposes an API GetNativeWindow to return the raw Win32 window handle. However, today few programmer would directly use Win32 API to write their GUI app other than .net.

  • Trade-off between flexibility and usability:

Since there is no clear usage model (or no dominating hybrid usage model), it is hard to make a decision between flexibility and usability. Would all CEF3 handlers be exported via WebView interface? Or just only expose some of them but which ones? For example, would it make sense to expose the multiple process architecture to user via IPC message handler?

CEF3 User Feedback

Some of this info is gathered from partners, incl. Adobe.

  • Lots of copy and paste
  • Kind of separate projects for Windows and Mac
  • Not everything working in Chrome will work in CEF
  • No sandboxing
  • Not easy to add custom APIs (especially in multi-process mode)
  • Manual memory management with CEF painful
  • Rebasing/Updating against Chromium
  • API design questionable
  • Single maintainership, bottleneck
  • ...

Alexis contacted Adobe to hear in writing what their issues with CEF are. Once we have this information, we'll add it here.

Add a custom footer

Introduction

Clone this wiki locally