- mac: Xcode 14.0 with macOS SDK 13.0 is now required.
- Remove CefRequestHandler::OnQuotaRequest because persistent quota is no
longer supported (see https://crbug.com/1208141)
Custom global and request context preferences can now be registered via
CefBrowserProcessHandler::OnRegisterCustomPreferences. CefRequestContext
now extends CefPreferenceManager and global preferences can be accessed
via CefPreferenceManager::GetGlobalPreferenceManager.
Change the default stack size to 8 MiB for 64-bit and 0.5 MiB for 32-bit.
CEF's main thread needs at least a 1.5 MiB stack size in order to avoid
stack overflow crashes. However, if this is set in the PE file then other
threads get this size as well, leading to address-space exhaustion in 32-bit
CEF. A new CefRunWinMainWithPreferredStackSize function uses fibers to switch
the main thread to a 4 MiB stack (roughly the same effective size as the
64-bit build's 8 MiB stack) before running any other code.
This change additionally moves the existing Windows-only functions
CefSetOSModalLoop and CefEnableHighDPISupport from cef_app.h to cef_win.h.
On Windows these new CefDisplay methods convert between screen pixel coordinates
and screen DIP coordinates. On macOS and Linux these methods just return a copy
of the input coordinates.
Disable BackForwardCache globally for the Alloy runtime so that
blink::RuntimeEnabledFeatures::BackForwardCacheEnables reports the
correct value in the renderer process.
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).
Calling DetachToUserFree() on a CefString holding a reference should copy the
value instead of transferring ownership.
A new `StringTest.Ownership` test has been added for this behavior.
With same-site BFCache enabled every navigation can now potentially be served
via the BFCache. To support this internally a new top-level RenderFrame object
may be created for each new navigation. As a result, OnBrowserCreated may now
be called multiple times with the same browser ID in a given renderer process
(a behavior previously only seen with cross-site navigations and different
renderer processes).
BFCache navigations do not trigger the same Chromium notifications as a normal
load. To avoid breaking CEF API usage expectations we now synthetically
generate the load-related callbacks that would otherwise be missing
(OnLoadingStateChange with isLoading=true, OnLoadStart, OnLoadEnd). The
|httpStatusCode| argument to OnLoadEnd will be 0 in this case.
To test:
- Run `FrameHandlerTest.*:MessageRouterTest.*:NavigationTest.*`
- Run `NavigationTest.LoadSameOriginLoadURL` for OnBrowserCreated behavior.
- Run `NavigationTest.History` for load-related callback behavior.
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 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.
With PdfUnseasoned the PDF file will be loaded in a dedicated renderer process.
We identify this process by adding the kPdfRenderer command-line flag (similar
to how kExtensionProcess is used to identify an extension renderer process). We
then avoid calling GetNewBrowserInfo for the PDF renderer process because we
know the request will otherwise time out.
We need to override ChromeMimeHandlerViewGuestDelegate to handle
OnGuestAttached/Detached callbacks in order to account for the guest renderer
process hosting the PDF extension.
Additional work will be required to account for the renderer process hosting the
PDF viewer when using `--enable-features=PdfUnseasoned` (see issue #2969).
- 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.
When BackForwardCache is enabled and the user navigates the main frame
back/forward a new RFH may be created for an existing main frame GlobalId value
and CefFrameHostImpl (e.g. an object that was previously Detach()ed after main
frame navigation called SetMainFrame, but for which RenderFrameDeleted was not
subsequently called due to insertion in the BackForwardCache). In this case we
can re-attach the new RFH to the existing main frame CefFrameHostImpl in
RenderFrameHostStateChanged and resume processing of messages.
Swapping back/forward to an existing (already loaded) renderer does not trigger
new notifications for draggable regions (e.g. RenderFrameObserver::
DraggableRegionsChanged is not called by default). We therefore explicitly
request an update of draggable regions by sending the DidStopLoading message to
the renderer.
A new |reattached| parameter is added to CefFrameHandler::OnFrameAttached to
support identification of BackForwardCache usage by the client.
To test with unit tests:
Run `ceftests --gtest_filter=DraggableRegionsTest.DraggableRegionsCrossOrigin
--enable-features=BackForwardCache`
To test manually:
1. Run `cefclient --enable-features=BackForwardCache --use-views
--url=http://tests/draggable`, note that draggable regions work.
2. Load https://www.google.com via the address bar, note that draggable regions
are removed.
3. Go back to http://tests/draggable, note that draggable regions work.
4. Go forward to https://www.google.com, note that draggable regions are
removed.
When BackForwardCache is enabled the old RFH tree may be cached instead of being
immediately deleted as a result of main frame navigation. If a RFH is cached
then delivery of the CefFrameHandler::OnFrameDetached callback will be delayed
until the the RFH is ejected from the cache (possibly not occurring until the
browser is destroyed). This change in OnFrameDetached timing was causing
FrameHandlerTest.OrderSubCrossOrigin* to fail, and the inclusion of cached
frames in CefBrowserInfo::GetAllFrames was causing
FrameTest.NestedIframesDiffOrigin to fail.
BackForwardCache is currently being tested via field trials (see
https://crbug.com/1171298) and can be explicitly disabled using the
`--disable-back-forward-cache` or `--disable-features=BackForwardCache`
command-line flags.
Automatically report unit tests to the TeamCity server if run within TeamCity.
See tests/gtest/teamcity/README.cef for details.
To test: Set the TEAMCITY_PROJECT_NAME environment variable and run ceftests.
Fixes the following error:
[FATAL:cef_bind_internal.h(868)] Check failed: receiver->HasAtLeastOneRef().
base::Bind{Once,Repeating}() refuses to create the first reference to ref-counted
objects. That typically happens around PostTask() in their constructor, and such
objects can be destroyed before `new` returns if the task resolves fast enough.
- 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.
ClientAppRenderer::Delegate callbacks are executed for all tests. In this case
CorsTest.IframeAllowScriptsCustomNonStandardSchemeToServer was crashing on Linux
because CefBrowser::GetMainFrame() returns nullptr in the renderer process when
called from a cross-origin sub-frame.
The AbortAfterCreated and AbortBeforeBrowse tests were flaking due to a race
between request handling and browser close. The tests would fail if the request
handling completed first.
See the new cef_frame_handler.h for complete usage documentation.
This change includes the following related enhancements:
- The newly added CefBrowser::IsValid method will return false (in the browser
process) after CefLifeSpanHandler::OnBeforeClose is called.
- CefBrowser::GetMainFrame will return a valid object (in the browser process)
until after CefLifeSpanHandler::OnBeforeClose is called.
- The main frame object will change during cross-origin navigation or
re-navigation after renderer process termination. During that time,
GetMainFrame will return the new/pending frame (in the browser process) and
any messages that arrive for the new/pending frame will be correctly
attributed in OnProcessMessageReceived.
- Commands to be executed in the renderer process that may fail during early
frame initialization (ExecuteJavaScript, LoadRequest, etc.) will now be
queued until after the JavaScript context for the frame has been created.
- Logging has been added for any commands that are dropped because they arrived
after frame detachment.
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().
With the Chrome runtime, Profile initialization may be asynchronous. Code that
waited on CefBrowserContext creation now needs to wait on CefBrowserContext
initialization instead.
The policy->CanAccessDataForOrigin CHECK in NavigationRequest::
GetOriginForURLLoaderFactory was failing because unregistered schemes
(which are already considered non-standard schemes) didn't trigger the
registered non-standard scheme allowance that we previously added in
ChildProcessSecurityPolicyImpl::CanAccessDataForOrigin. This change
modifies GetOriginForURLLoaderFactory to always return an opaque/unique
origin for non-standard schemes resulting in unregistered and non-standard
schemes receiving the same treatment.
New test coverage has been added for this condition, and can be run with:
ceftests --gtest_filter=CorsTest.*CustomUnregistered*
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.
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.
Marshall Greenblatt
npavlov
VodBox
Jelle Bleyaert
Dmitry Azaraev
JohnKarel