Existing UI thread shutdown tasks need to be executed before the UI
thread RunLoop is terminated. Those tasks have now been moved to
CefMainRunner::StartShutdownOnUIThread and FinishShutdownOnUIThread is
now called after the RunLoop is terminated.
This fixes a shutdown crash in ChromeProcessSingleton::DeleteInstance.
DeleteInstance needs to be called on the UI thread near the end of the
shutdown process (after ChromeProcessSingleton::Cleanup is called via
PostMainMessageLoopRun).
Disable Chrome policy management by default. Add CefSettings.chrome_policy_id
which, when configured, enables Chrome policy management. See
https://support.google.com/chrome/a/answer/9037717 for background.
To test:
- Start with a machine where Google Chrome is managed.
- Run `cefclient --enable-chrome-runtime --url=chrome://policy/`
There should be no configured policies.
- Run `cefclient --enable-chrome-runtime --url=chrome://policy/
--enable-chrome-policy`
Configured Platform properties should match Google Chrome.
- Run `cefclient --enable-chrome-runtime --url=chrome://policy/
--enable-chrome-policy --enable-chrome-browser-cloud-management`
Configured Platform and Cloud properties should match Google Chrome.
This avoids a situation where misbehaving clients may cause the
application to continue running indefinitely by posting new UI
thread tasks after calling CefQuitMessageLoop.
- Remove CefRequestContextHandler::OnBeforePluginLoad and
CefRequestContext::PurgePluginListCache (fixes issue #3047). These methods
stopped being relevant after the removal of Flash support in January 2021.
The last remaining PPAPI plugin (PDF viewer) will switch to a non-plugin
implementation in the near future (see https://crbug.com/702993#c58) and
functionality related to plugin filtering has already been removed in
https://crrev.com/343ae351c9.
This change introduces a few minor CEF API behavior changes:
- A CefProcessMessage object cannot be reused after being passed to
SendProcessMessage.
- The |extra_info| argument to CefRenderProcessHandler::OnBrowserCreated may
now be NULL.
Where appropriate, we now utilize the default UTF string encoding format and
shared memory to reduce copies and conversions for the cross-process
transfer of arbitrary-length strings. For example, CefFrame::GetSource/GetText
now involves zero UTF conversions and zero copies in the browser process for
the CefString delivered to CefStringVisitor::Visit().
This change adds support for:
- Protocol and request handling.
- Loading and navigation events.
- Display and focus events.
- Mouse/keyboard events.
- Popup browsers.
- Callbacks in the renderer process.
- Misc. functionality required for ceftests.
This change also adds a new CefBrowserProcessHandler::GetCookieableSchemes
callback for configuring global state that will be applied to all
CefCookieManagers by default. This global callback is currently required by the
chrome runtime because the primary ProfileImpl is created via
ChromeBrowserMainParts::PreMainMessageLoopRun (CreatePrimaryProfile) before
OnContextCreated can be called.
ProfileImpl will use the "C:\Users\[user]\AppData\Local\CEF\User Data\Default"
directory by default (on Windows). Cookies may persist in this directory when
running ceftests and may need to be manually deleted if those tests fail.
Remaining work includes:
- Support for client-created request contexts.
- Embedding the browser in a Views hierarchy (cefclient support).
- TryCloseBrowser and DoClose support.
- Most of the CefSettings configuration.
- DevTools protocol and window control (ShowDevTools, ExecuteDevToolsMethod).
- CEF-specific WebUI pages (about, license, webui-hosts).
- Context menu customization (CefContextMenuHandler).
- Auto resize (SetAutoResizeEnabled).
- Zoom settings (SetZoomLevel).
- File dialog runner (RunFileDialog).
- File and JS dialog handlers (CefDialogHandler, CefJSDialogHandler).
- Extension loading (LoadExtension, etc).
- Plugin loading (OnBeforePluginLoad).
- Widevine loading (CefRegisterWidevineCdm).
- PDF and print preview does not display.
- Crash reporting is untested.
- Mac: Web content loads but does not display.
The following ceftests are now passing when run with the
"--enable-chrome-runtime" command-line flag:
CorsTest.*
DisplayTest.*:-DisplayTest.AutoResize
DOMTest.*
DraggableRegionsTest.*
ImageTest.*
MessageRouterTest.*
NavigationTest.*
ParserTest.*
RequestContextTest.*Global*
RequestTest.*
ResourceManagerTest.*
ResourceRequestHandlerTest.*
ResponseTest.*
SchemeHandlerTest.*
ServerTest.*
StreamResourceHandlerTest.*
StreamTest.*
StringTest.*
TaskTest.*
TestServerTest.*
ThreadTest.*
URLRequestTest.*Global*
V8Test.*:-V8Test.OnUncaughtExceptionDevTools
ValuesTest.*
WaitableEventTest.*
XmlReaderTest.*
ZipReaderTest.*
- CefURLRequest::Create is no longer supported in the renderer process
(see https://crbug.com/891872). Use CefFrame::CreateURLRequest instead.
- Mac platform definitions have been changed from `MACOSX` to `MAC`
(see https://crbug.com/1105907) and related CMake macro names have
been updated. The old `OS_MACOSX` define is still set in code and CMake
for backwards compatibility.
- Linux ARM build is currently broken (see https://crbug.com/1123214).
This change moves shared resource initialization to a common location and
disables crash reporting initialization in chrome/ code via patch files.
When using the Chrome runtime on macOS the Chrome application window will
display, but web content is currently blank and the application does not
exit cleanly. This will need to be debugged further in the future.
This change adds basic Chrome runtime implementations for CefBrowserContext
and CefBrowserPlatformDelegate. A Chrome browser window with default frame
and styling can now be created using CefBrowserHost::CreateBrowser and some
CefClient callbacks will be triggered via the WebContentsObserver
implementation in CefBrowserHostImpl.
Any additional browser windows created via the Chrome UI will be unmanaged
by CEF. The application message loop will block until all browser windows
have been closed by the user.
Existing CefBrowserContext functionality is now split between
CefBrowserContext and AlloyBrowserContext. Runtime implementations of
CefBrowserContext will provide access to the content::BrowserContext and
Profile types via different inheritance paths. For example, the Alloy
runtime uses ChromeProfileAlloy and the Chrome runtime uses ProfileImpl.
This change also renames CefResourceContext to CefIOThreadState to more
accurately represent its purpose as it no longer needs to extend
content::ResourceContext.
This is the first pass in removing direct dependencies on the Alloy
runtime from code that can potentially be shared between runtimes.
CefBrowserHost and CefRequestContext APIs (including CefCookieManager,
CefURLRequest, etc.) are not yet implemented for the Chrome runtime.
Assert early if these API methods are called while the Chrome runtime
is enabled.
Running `cefsimple --enable-chrome-runtime` will create and run a
Chrome browser window using the CEF app methods, and call
CefApp::OnContextInitialized as expected. CEF task methods also
work as expected in the main process. No browser-related methods or
callbacks are currently supported for the Chrome window, and the
application will exit when the last Chrome window closes.
The Chrome runtime requires resources.pak, chrome_100_percent.pak
and chrome_200_percent.pak files which were not previously built
with CEF. It shares the existing locales pak files which have been
updated to include additional Chrome-specific strings.
On Linux, the Chrome runtime requires GTK so use_gtk=true must be
specified via GN_DEFINES when building.
This change also refactors the CEF runtime, which can be tested in
the various supported modes by running:
$ cefclient
$ cefclient --multi-threaded-message-loop
$ cefclient --external-message-pump
Marshall Greenblatt