The cefclient sample app will persist window state across application restart
if run with views, cache_path and persist_user_references enabled.
To test:
1. Run `cefclient --use-views --cache-path=/path/to/cache --persist-user-preferences`
2. Move or resize the window, maximize, minimize, etc.
3. Exit cefclient.
4. Run cefclient again with the same arguments. The previous window state will
be restored.
Use ScreenWin functions to correctly compute DIP/pixel conversions for
CEF-created top-level windows.
Fix incorrect DIPToScreenRect usage in DesktopWindowTreeHostWin when
|has_external_parent_| is true.
CefSharedProcessMessageBuilder supports creation of a CefProcessMessage
backed by a CefSharedMemoryRegion.
Performance tests comparing the existing ArgumentList approach and the new
SharedMemoryRegion approach have been added to cefclient at
http://tests/ipc_performance.
CefMessageRouter has been updated to use SharedMemoryRegion as transport
for larger message payloads. The threshold is configurable via
|CefMessageRouterConfig.message_size_threshold|.
To test:
run `ceftests --gtest_filter=SendSharedProcessMessageTest.*:SharedProcessMessageTest.*:MessageRouterTest.Threshold*`
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).
This change provides a generic solution for active (key) window tracking that
works with both Views-hosted and native windows on MacOS. With this new approach
we can now successfully route top menu actions to the currently active window.
Prior to this change CEF's Views API was using focus notifications as a proxy
for window activation notifications. That doesn't work on MacOS where NSWindow
activation (key status) is independent of NSView focus (first responder) status,
and changes in activation don't necessarily generate focus notifications (see
NativeWidgetMac::OnWindowKeyStatusChanged). To make this work reliably on all
platforms we now expose a CefWindowDelegate::OnWindowActivationChanged callback.
This change also fixes an uninitialized variable
(RootWindowMacImpl::with_extension_) that was causing flaky behavior in
RootWindowManager::OnRootWindowActivated.
To test:
1. Run `cefclient [--use-views]`
2. Select Popup Window from the Tests menu. Do not explicitly activate the popup
window (e.g. don't click on it).
3. Verify that further Tests menu actions go to the popup window.
4. Change activation to a first window by clicking on it. Verify that Test
menu actions go to that window.
5. Close the currently active window. Do not explicitly activate the remaining
window (e.g. don't click on it).
6. Verify that Test menu actions go to the only remaining window.
Popup windows will be created on the display that best matches the requested
coordinates. The requested size will apply to the content area (as required by
JS documentation) and window size will be reduced if necessary to fit within the
target display. The requested origin will apply to the window (including frame)
and will be modified if necessary so that the window is fully visible on the
target display.
This change adds a `--use-default-popup` command-line option to cefclient. When
specified, popup windows will be created with default styling (e.g. without an
application-provided native parent window).
This change also adds some reasonable default window bounds in cases where they
are not specified by the client.
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.
This change adds a CefDownloadHandler::CanDownload callback for optionally
blocking user-initiated downloads (e.g. alt + link click or link click that
returns a `Content-Disposition: attachment` response from the server).
To test:
- Run `ceftests --gtest_filter=DownloadTest.*`.
- Run `cefclient --hide-controls`. User-initiated downloads will be blocked.
This change adds a CefCommandHandler::OnChromeCommand callback for optionally
handling Chrome commands triggered via menus or keyboard shortcuts. Supported
command IDs are listed in a new cef_command_ids.h header file.
To test: Run `cefclient --enable-chrome-runtime --hide-controls`. Most commands
will blocked and removed from context menus.
This change adds `CefBrowserSettings.chrome_status_bubble` for controlling
whether the Chrome status bubble will be used.
Testable in cefclient by passing the `--hide-chrome-status-bubble`
command-line flag.
This functionality 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 (PdfUnseasoned) in M100.
- 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.
To test:
Run `cefclient.exe --use-views --hide-frame --hide-controls`
Add `--enable-chrome-runtime` for the same behavior using the Chrome location
bar instead of a text field.
Widevine CDM binaries will be downloaded on supported platforms shortly after
application startup. Widevine support will then become available within a few
seconds after successful installation on Windows or after the next application
restart on other platforms. The CDM files will be downloaded to a "WidevineCdm"
directory inside the `CefSettings.user_data_path` directory.
Pass the `--disable-component-update` command-line flag to disable Widevine
download and installation. Pass the `--component-updater=fast-update` command-
line flag to force Widevine download immediately after application startup.
See the related issue for additional usage details.
- Convert scoped_ptr to std::unique_ptr from <memory>
- Convert arraysize to base::size from include/base/cef_cxx17_backports.h
- Convert NULL to nullptr
- Include include/base/cef_callback.h instead of include/base/cef_bind.h
- Implicit conversion of CefRefPtr<T> or scoped_refptr<T> to T* is gone;
use .get() instead
See the issue for additional details.
This change adds support for CEF settings configuration of accept_language_list.
If specified, this value will take precedence over the "intl.accept_languages"
preference which is controlled by chrome://settings/languages.
With the Chrome runtime, Profile initialization may be asynchronous. Code that
waited on CefBrowserContext creation now needs to wait on CefBrowserContext
initialization instead.
The Chrome runtime requires that cookieable scheme information be available
at Profile initialization time because it also triggers NetworkContext creation
at the same time. To make this possible, and to avoid various race conditions
when setting state, the cookieable scheme configuration has been added as
|cookieable_schemes_list| and |cookieable_schemes_exclude_defaults| in
CefSettings and CefBrowserContextSettings. The CefCookieManager::
SetSupportedSchemes and CefBrowserProcessHandler::GetCookieableSchemes methods
are no longer required and have been removed.
This change also modifies chrome to delay OffTheRecordProfileImpl initialization
so that |ChromeBrowserContext::profile_| can be set before
ChromeContentBrowserClientCef::ConfigureNetworkContextParams calls
CefBrowserContext::FromBrowserContext to retrieve the ChromeBrowserContext
and associated cookieable scheme information. Otherwise, the
ChromeBrowserContext will not be matched and the NetworkContext will not be
configured correctly.
The CookieTest suite now passes with the Chrome runtime enabled.
GTK3 is required by the Chrome runtime. The cefclient off-screen rendering
example no longer works with Ubuntu 16.04. With end-of-life in April 2021
we are dropping support for 16.04 in the near future in any case.
The Chrome browser can now be hosted in a Views-based application on Mac
(see issue #2969).
To launch a fully-featured Chrome window using cefsimple:
$ open cefsimple.app --args --enable-chrome-runtime
To launch a minimally-styled Views-hosted window using cefsimple:
$ open cefsimple.app --args --use-views [--enable-chrome-runtime]
To launch a fully-styled Views-hosted window using cefclient:
$ open cefclient.app --args --use-views [--enable-chrome-runtime]
Known issues:
- Some Views unit tests are currently failing on Mac.
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.
Switch to using g_main_context_default() in MainMessageLoopMultithreadedGtk. As of M86
(https://crrev.com/b960daf4e6) Chromium now creates its own context in MessagePumpGlib so
we can use the default context in cefclient. This is also more "correct" from a GTK usage
perspective. As part of this change all GTK dialogs and callbacks are now executed on the
main thread instead of the UI thread (note that these are the same thread when not using
multi-threaded-message-loop).
The cursor change can now be handled by the client with both windowed and
off-screen rendering.
Returning true from OnCursorChange will disable the default cursor change
behavior. This is functionally equivalent to the
CefBrowserHost::SetMouseCursorChangeDisabled method, so that method has been
removed.
- 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).
- Windows: 10.0.19041 SDK is now required.
- macOS: 10.15.1 SDK (at least Xcode 11.2) is now required.
- Remove CefMediaSource::IsValid and CefMediaSink::IsValid which would
always return true.
This change allows the client to directly send and receive DevTools
protocol messages (send method calls, and receive method results and
events) without requiring a DevTools front-end or remote-debugging
session.
This change includes additional supporting changes:
- Add a new CefRequestHandler::OnDocumentAvailableInMainFrame
callback (see issue #1454).
- Add a CefParseJSON variant that accepts a UTF8-encoded buffer.
- Add a `--devtools-protocol-log-file=<path>` command-line flag for
logging protocol messages sent to/from the DevTools front-end
while it is displayed. This is useful for understanding existing
DevTools protocol usage.
- Add a new "libcef_static_unittests" executable target to support
light-weight unit tests of libcef_static internals (e.g. without
requiring exposure via the CEF API). Files to be unittested are
placed in the new "libcef_static_unittested" source_set which is
then included by both the existing libcef_static library and the
new unittests executable target.
- Linux: Remove use_bundled_fontconfig=false, which is no longer
required and causes unittest build errors (see issue #2424).
This change also adds a cefclient demo for configuring offline mode
using the DevTools protocol (fixes issue #245). This is controlled
by the "Offline mode" context menu option and the `--offline`
command-line switch which will launch cefclient in offline mode. When
cefclient is offline all network requests will fail with
ERR_INTERNET_DISCONNECTED and navigator.onLine will return false when
called from JavaScript in any frame. This mode is per-browser so
newly created browser windows will have the default mode. Note that
configuring offline mode in this way will not update the Network tab
UI ("Throtting" option) in a displayed DevTools front-end instance.
This attribute is useful for identifying different classes of cast devices
without first requiring a connection (CAST, CAST_AUDIO, CAST_AUDIO_GROUP, etc).
Chromium supports communication with media devices on the local network via
the Cast and DIAL protocols. This takes two primary forms:
1. Messaging, where strings representing state information are passed between
the client and a dedicated receiver app on the media device. The receiver
app communicates directly with an app-specific backend service to retrieve
and possibly control media playback.
2. Tab/desktop mirroring, where the media contents are streamed directly from
the browser to a generic streaming app on the media device and playback is
controlled by the browser.
This change adds support for device discovery and messaging (but not
mirroring) with functionality exposed via the new CefMediaRouter interface.
To test: Navigate to http://tests/media_router in cefclient and follow the
on-screen instructions.
When NetworkService is enabled requests created using CefFrame::CreateURLRequest
will call CefRequestHandler::GetAuthCredentials for the associated browser after
calling CefURLRequestClient::GetAuthCredentials if that call returns false.
This change moves the SendProcessMessage method from CefBrowser to CefFrame and
adds CefBrowser parameters to OnProcessMessageReceived and
OnDraggableRegionsChanged.
The internal implementation has changed as follows:
- Frame IDs are now a 64-bit combination of the 32-bit render_process_id and
render_routing_id values that uniquely identify a RenderFrameHost (RFH).
- CefFrameHostImpl objects are now managed by CefBrowserInfo with life span tied
to RFH expectations. Specifically, a CefFrameHostImpl object representing a
sub-frame will be created when a RenderFrame is created in the renderer
process and detached when the associated RenderFrame is deleted or the
renderer process in which it runs has died.
- The CefFrameHostImpl object representing the main frame will always be valid
but the underlying RFH (and associated frame ID) may change over time as a
result of cross-origin navigations. Despite these changes calling LoadURL on
the main frame object in the browser process will always navigate as expected.
- Speculative RFHs, which may be created as a result of a cross-origin
navigation and discarded if that navigation is not committed, are now handled
correctly (e.g. ignored in most cases until they're committed).
- It is less likely, but still possible, to receive a CefFrame object with an
invalid frame ID (ID < 0). This can happen in cases where a RFH has not yet
been created for a sub-frame. For example, when OnBeforeBrowse is called
before initiating navigation in a previously nonexisting sub-frame.
To test: All tests pass with NetworkService enabled and disabled.
The optional |extra_info| parameter provides an opportunity to specify extra
information specific to the created browser that will be passed to
CefRenderProcessHandler::OnBrowserCreated() in the render process.
Implementation notes:
- Chromium change: CookieMonster::SetCookieableSchemes needs to be called
immediately after the CookieMonster is created in NetworkContext::
ApplyContextParamsToBuilder. Add a Profile::GetCookieableSchemes method and
NetworkContextParams.cookieable_schemes member (set from
ProfileNetworkContextService::CreateNetworkContextParams) to support that.
- Chromium change: Add a ContentBrowserClient::HandleExternalProtocol variant
that exposes additional NetworkService request information.
- GetResourceResponseFilter is not yet implemented.
API changes:
- Resource-related callbacks have been moved from CefRequestHandler to a new
CefResourceRequestHandler interface which is returned via the
GetResourceRequestHandler method. If the CefRequestHandler declines to handle
a resource it can optionally be handled by the CefRequestContextHandler, if
any, associated with the loading context.
- The OnProtocolExecution callback has been moved from CefRequestHandler to
CefResourceRequestHandler and will be called if a custom scheme request is
unhandled.
- Cookie send/save permission callbacks have been moved from CefRequestHandler
and CefResourceHandler to CefResourceRequestHandler.
- New methods added to CefResourceHandler that better match NetworkService
execution sequence expectations. The old methods are now deprecated.
- New methods added to CefRequest and CefResponse.
Known behavior changes with the NetworkService implementation:
- Modifying the |new_url| parameter in OnResourceRedirect will no longer result
in the method being called an additional time (likely a bug in the old
implementation).
- Modifying the request URL in OnResourceResponse would previously cause a
redirect. This behavior is now deprecated because the NetworkService does not
support this functionality when using default network loaders. Temporary
support has been added in combination with CefResourceHandler usage only.
- Other changes to the request object in OnResourceResponse will now cause the
request to be restarted. This means that OnBeforeResourceLoad, etc, will be
called an additional time with the new request information.
- CefResponse::GetMimeType will now be empty for non-200 responses.
- Requests using custom schemes can now be handled via CefResourceRequestHandler
with the same callback behavior as builtin schemes.
- Redirects of custom scheme requests will now be followed as expected.
- Default handling of builtin schemes can now be disabled by setting
|disable_default_handling| to true in GetResourceRequestHandler.
- Unhandled requests (custom scheme or builtin scheme with default handling
disabled) will fail with an CefResponse::GetError value of
ERR_UNKNOWN_URL_SCHEME.
- The CefSchemeHandlerFactory::Create callback will now include cookie headers.
To test:
- Run `cefclient --enable-network-service`. All resources should load
successfully (this tests the transparent proxy capability).
- All tests pass with NetworkService disabled.
- The following tests pass with NetworkService enabled:
- CookieTest.*
- FrameTest.* (excluding .*Nav)
- NavigationTest.* (excluding .Redirect*)
- RequestHandlerTest.*
- RequestContextTest.Basic*
- RequestContextTest.Popup*
- RequestTest.*
- ResourceManagerTest.*
- ResourceRequestHandlerTest.* (excluding .Filter*)
- SchemeHandlerTest.*
- StreamResourceHandlerTest.*
Under ARC (Automatic Reference Counting), assigning to an Objective-C
pointer has different semantics than assigning to a void* pointer.
This makes it dangerous to treat the same memory address as an
Objective-C pointer in some cases and as a "regular C pointer" in
other cases.
This change removes the conditional type defines and instead uses
void* everywhere. Explicit type casting in combination with ARC
annotations makes it safe to get typed Objective-C pointers from the
void* pointers.
This change enables ARC by default in the CEF binary distribution CMake
configuration for the cefclient and cefsimple sample applications. It can be
disabled by adding `-DOPTION_USE_ARC=Off` to the CMake command line.
ARC is not supported when building Chromium due to the substantial
number of changes that would be required in the Chromium code base.
This change adds a new CefSettings.root_cache_path value that must be either
equal to or a parent directory of all CefSettings.cache_path and
CefRequestContextSettings.cache_path values. The sandbox may block read/write
access from the NetworkService to directories that do not meet this requirement.
To test: Run cefclient with a combination of the following flags:
--cache-path=c:\temp\cache
Cache data should be persisted to the specified directory.
--request-context-per-browser
A separate numbered cache directory should be created underneath the
cache-path directory for each new browser instance.
--enable-network-service --disable-extensions
Same tests, but with NetworkService enabled.
Known issues:
- When NetworkService is enabled a C:\temp\cache\cache\Cache directory is
created (should be C:\temp\cache\Cache).
This change removes cookie and request handler functionality that will not
supported by the NetworkService. Specifically, it is no longer possible to
change cookie storage locations at runime by returning a different
CefCookieManager for an already initialized CefRequestContext. After this change
you will need to use a separate CefRequestContext when creating a CefBrowser if
you require separate cookie storage.
The following methods have been removed:
- CefCookieManager::CreateManager
- CefCookieManager::GetBlockingManager
- CefCookieManager::SetStoragePath
- CefRequestContextHandler::GetCookieManager
The following methods have been renamed:
- CefRequestContext::GetDefaultCookieManager to GetCookieManager.
This change substantially simplifies the network implementation in CEF because
it is no longer necessary to proxy objects that are normally owned by Chromium.
Chromium patches that are no longer necessary will be removed as a follow-up
commit.
To test: Verify that `ceftests --gtest_filter=-PluginTest.*` pass with
NetworkService disabled. Plugin tests will be fixed in a follow-up commit.