When running with the overlay Browser enabled (`--show-overlay-browser`),
pressing Alt+O will move the overlay Browser to a new top-level Window.
Pressing Alt+O again or closing the new Window via the close button will
return the Browser to the overlay. Closing the Browser via `window.close()`
(in the new Window or overlay) will dismiss the overlay completely as
required to maintain consistent internal state. Detection of this state is
supported by the new CefBrowserHost::IsReadyToBeClosed method.
Draggable regions in the main Browser are updated to account for the
presence or absence of the overlay Browser. Support for draggable regions
in the overlay Browser in not implemented in cefclient.
Behavior with multiple overlays, `window.close()` and draggable regions
can be tested by adding `--hide-frame --hide-controls`.
Avoid a circular ownership dependency between CefBrowserViewImpl and
CefBrowserPlatformDelegate[Chrome]Views (owned by CefBrowserHostBase).
Trigger CefBrowserHostBase destruction when the last CefBrowserViewImpl
reference is released.
This fixes a number of shutdown crashes related to overlay CefBrowsers
still existing at CefShutdown.
Found using a CEF build with clang_use_chrome_plugins=true
and treat_warnings_as_errors=false.
This change rewrites remaining raw pointers reported by
chromium-rawptr checker and fixes a build error reported
by StackAllocatedChecker.
Set enable_alloy_bootstrap=false to build with Alloy bootstrap code
removed. Extension API is documented as deprecated in comments but
not compiled out with this arg.
Split the Alloy runtime into bootstrap and style components. Support
creation of Alloy style browsers and windows with the Chrome runtime.
Chrome runtime (`--enable-chrome-runtime`) + Alloy style
(`--use-alloy-style`) supports Views (`--use-views`), native parent
(`--use-native`) and windowless rendering
(`--off-screen-rendering-enabled`).
Print preview is supported in all cases except with windowless rendering
on all platforms and native parent on MacOS. It is disabled by default
with Alloy style for legacy compatibility. Where supported it can be
enabled or disabled globally using `--[enable|disable]-print-preview` or
configured on a per-RequestContext basis using the
`printing.print_preview_disabled` preference. It also behaves as
expected when triggered via the PDF viewer print button.
Chrome runtime + Alloy style behavior differs from Alloy runtime in the
following significant ways:
- Supports Chrome error pages by default.
- DevTools popups are Chrome style only (cannot be windowless).
- The Alloy extension API will not supported.
Chrome runtime + Alloy style passes all expected Alloy ceftests except
the following:
- `DisplayTest.AutoResize` (Alloy extension API not supported)
- `DownloadTest.*` (Download API not yet supported)
- `ExtensionTest.*` (Alloy extension API not supported)
This change also adds Chrome runtime support for
CefContextMenuHandler::RunContextMenu (see #3293).
This change also explicitly blocks (and doesn't retry) FrameAttached
requests from PDF viewer and print preview excluded frames (see #3664).
Known issues specific to Chrome runtime + Alloy style:
- DevTools popup with windowless rendering doesn't load successfully.
Use windowed rendering or remote debugging as a workaround.
- Chrome style Window with Alloy style BrowserView (`--use-alloy-style
--use-chrome-style-window`) does not show Chrome theme changes.
To test:
- Run `ceftests --enable-chrome-runtime --use-alloy-style
[--use-chrome-style-window] [--use-views|--use-native]
--gtest_filter=...`
- Run `cefclient --enable-chrome-runtime --use-alloy-style
[--use-chrome-style-window]
[--use-views|--use-native|--off-screen-rendering-enabled]`
- Run `cefsimple --enable-chrome-runtime --use-alloy-style [--use-views]`
All file dialogs irrespective of source, platform and runtime will now be
routed through CefFileDialogManager and trigger CefDialogHandler callbacks
(see issue #3293).
Adds Chrome runtime support for CefBrowserHost::RunFileDialog and
CefDialogHandler callbacks.
Adds Alloy runtime support for internal GTK file and print dialogs on Linux
subject to the following limitations:
1. Internal GTK implementation:
- Cannot be used with multi-threaded-message-loop because Chromium's
internal GTK implementation is not thread-safe (does not use GDK threads).
- Dialogs will not be modal to application windows when used with off-screen
rendering due to lack of access to the client's top-level GtkWindow.
2. Cefclient CefDialogHandler implementation:
- Cannot be used with Views because it requires a top-level GtkWindow.
Due to the above limitations no dialog implementation is currently provided for
Views + multi-threaded-message-loop on Linux. In cases where both
implementations are supported the cefclient version is now behind an optional
`--use-client-dialogs` command-line flag.
Expressly forbids multiple simultaneous file dialogs with the internal platform
implementation which uses modal dialogs. CefDialogHandler will still be notified
and can optionally handle each request without a modal dialog (see issue #3154).
Removes some RunFileDialog parameters that are not supported by the Chrome file
dialog implementation (selected_accept_filter parameter, cef_file_dialog_mode_t
overwrite/read-only flags).
When using a Views-hosted browser window the client receives Views-related
callbacks for popups and can thereby customize the Views-hosted popup behavior.
When using an external parent window no Views-related callbacks are delivered
and customization options are restricted to providing a new parent handle via
OnBeforePopup. Consequently, we should default to a normal browser window in
the external parent case instead of the very minimial Views-hosted default.
To test (A):
1. Run `cefclient --use-default-popup --enable-chrome-runtime --use-native`
2. Select Tests > Popup Window
3. Get a normal Chrome browser window
To test (B):
1. Run `cefclient --use-default-popup [--enable-chrome-runtime] [--use-views]`
2. Select Tests > Popup Window
3. Get a native or Views-hosted browser window with title bar only
This change adds Chrome runtime support on Windows and Linux for creating a
browser parented to a native window supplied by the client application.
Expected API usage and window behavior is similar to what already exists with
the Alloy runtime. The parent window handle should be specified by using
CefWindowInfo::SetAsChild in combination with the CefBrowserHost::CreateBrowser
and CefLifeSpanHandler::OnBeforePopup callbacks.
The previously existing behavior of creating a fully-featured Chrome browser
window when empty CefWindowInfo is used with CreateBrowser remains unchanged
and Views is still the preferred API for creating top-level Chrome windows
with custom styling (e.g. title bar only, frameless, etc).
The cefclient Popup Window test with a native parent window continues to crash
on Linux with both the Alloy and Chrome runtimes (see issue #3165).
Also adds Chrome runtime support for CefDisplayHandler::OnCursorChange.
To test:
- Run `cefclient --enable-chrome-runtime [--use-views]` for the default (and
previously existing) Views-based behavior.
- Run `cefclient --enable-chrome-runtime --use-native` for the new native
parent window behavior.
- Run `cefclient --enable-chrome-runtime --use-native --no-activate` and the
window will not be activated (take input focus) on launch (Windows only).
- Run `cefclient --enable-chrome-runtime [--use-views|--use-native]
--mouse-cursor-change-disabled` and the mouse cursor will not change on
mouseover of DOM elements.
The Chrome browser can now be hosted in a Views-based application on Windows
and Linux.
To launch a fully-featured Chrome window using cefsimple:
$ cefsimple --enable-chrome-runtime
To launch a minimally-styled Views-hosted window using cefsimple:
$ cefsimple --enable-chrome-runtime --use-views
To launch a fully-styled Views-hosted window using cefclient:
$ cefclient --enable-chrome-runtime --use-views
Views unit tests also now pass with the Chrome runtime enabled:
$ ceftests --gtest_filter=Views* --enable-chrome-runtime
Known issues:
- Popup browsers cannot be intercepted and reparented.
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 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.
This change moves the runtime-specific implementations of CefBrowserHostImpl
methods to CefBrowserPlatformDelegate. Some WebContentsDelegate methods
implemented by CefBrowserHostImpl set state or trigger client callbacks.
Those implementations will likely stay with CefBrowserHostImpl and will
need to be called from the Browser equivalents when using the Chrome runtime.
The PDF loading documentation in extension_system.cc has be updated to
describe the new code paths.
To support delivery of input events to the mime handler renderer process it is
now necessary to route events via the correct RWHV interface. For Aura-based
platforms (Windows/Linux) this means RWHVAura::On*Event and for macOS this
means RWHVMac::RouteOrProcess*Event. Since Aura uses UI event types these have
become the source of truth on Aura-based platforms with conversion to Web event
types when needed (primarily for OSR).
This change also adds a timeout for CefProcessHostMsg_GetNewBrowserInfo to
avoid a hung renderer process if the guest WebContents route is not
registered via CefMimeHandlerViewGuestDelegate::OnGuestDetached as expected
prior to CefBrowserInfoManager::OnGetNewBrowserInfo being called. This
timeout can be disabled for testing purposes by passing the
`--disable-new-browser-info-timeout` command-line flag.
The `--disable-features=MimeHandlerViewInCrossProcessFrame` command-line
flag can be used for a limited time to restore the previous implementation
based on BrowserPlugin. That implementation will be deleted starting with
the 3897 branch update.
Known issues:
- ExecuteJavaScript calls on the frame hosting the PDF extension will not
be routed to the mime handler renderer process.
- The PDF extension will not load successfully if blocked by
ChromePluginPlaceholder and then manually continued via the "Run this
plugin" context menu option (see https://crbug.com/533069#c41).
- Add CefWindowInfo::shared_texture_enabled and
CefRenderHandler::OnAcceleratedPaint for shared texture support. Currently
only supported on Windows (D3D11).
- Add CefWindowInfo::external_begin_frame_enabled and
CefBrowserHost::SendExternalBeginFrame for external begin frame support.
- Add new CefBrowserHost::SetAccessibilityState method for toggling
accessibility state when readers are detected by the client.
- Add new CefAccessibilityHandler interface for the delivery of
accessibility notifications to windowless (OSR) clients.
- Fix delivery of CefFocusHandler callbacks to windowless clients.
- cefclient: Add example windowless accessibility implementation on Windows and macOS.
- cefclient: Automatically detect screen readers on Windows and macOS.
Nik Pavlov
Marshall Greenblatt
Yuta Sekiguchi
Vladislav
Ananyo Maiti
Greg Wessels
Nishant Kaushik