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.
A reference to a received CefProcessMessage object and/or associated argument
list can now be kept outside of the OnProcessMessageReceived callback. The
argument list is no longer explicitly owned by the CefProcessMessage object
and can be individually assigned to other CefValue types as needed (e.g. by
passing to SetList, etc). Depending on client usage this could reduce the
potential for unnecessary copies of the list contents.
Received messages can also be sent back using SendProcessMessage (after which
the CefProcessMessage would become invalid as discussed in issue #3123). This
is not new behavior but we have now added explicit unit test coverage for it.
This also no longer requires a copy of the argument list contents.
Note that a received argument list is initially read-only for logical
consistency. Assignment to another CefValue object could potentially remove
the read-only status because it is not an intrinsic property of the underlying
Chromium data type. This is fine because, at that point, ownership has been
transfered to the new CefValue object and the original logical context (as
part of the CefProcessMessage) no longer applies.
When navigating cross-origin a speculative RenderFrameHost (RFH) and
CefFrameHostImpl is created in the browser process for the new frame object
created in a new renderer process. The FrameAttached message then arrives for
the speculative RFH, and as a consequence interfaces are bound between the new
CefFrameHostImpl and the speculative RFH. If the pending navigation commits
then the existing RFH will be replaced with the previously speculative RFH.
Since interfaces are already bound we must keep the new CefFrameHostImpl. This
means that frame objects (including for the main frame) will now always change
after cross-origin navigation, and the old frame object will be invalidated.
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().
Restore the async CreateBrowser behavior that existed prior to commit 691c9c2
because executing synchronously (for example, from inside OnContextInitialized)
causes issues on MacOS and possibly other platforms.
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.
Iterator debugging has been disabled by default (_HAS_ITERATOR_DEBUGGING=0)
for CEF/Chromium builds using clang/LLVM since 2018. Inversely, it is enabled
by default (_ITERATOR_DEBUG_LEVEL=2) for the MSVC Debug build configuration.
In order to minimize configuration-related headaches for MSVC-based clients
we have been building the Debug cef_sandbox.lib with iterator debugging
enabled. Recently, we have identified a number of crashes that may be due to
bugs in current clang/LLVM or MSVC versions but in any case can be resolved by
disabling iterator debugging:
- Crash when loading chrome://sandbox.
- Crash if an application lists libraries that utilize iterators after
cef_sandbox.lib in the linker order.
To resolve these crashes we will now disable iterator debugging by default
for the cef_sandbox.lib builds. Client applications that link cef_sandbox.lib
will now also need to build with iterator debugging disabled by setting
_HAS_ITERATOR_DEBUGGING=0 or _ITERATOR_DEBUG_LEVEL=0 in their project
configuration (this will be done for you if you use cef_variables.cmake from
the binary distribution).
In addition to the crash fixes mentioned above, this change also:
- Reduces the size of the Debug cef_sandbox.lib by ~10MB.
- May result in faster Debug executables (see https://crbug.com/539996).
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*
Profile::IsIncognitoProfile() currently returns false for CEF incognito profiles
because they are not the primary OTR profile. At the same time, we don't
necessarily want IsIncognitoProfile() to return true for CEF profiles because,
among other things, that causes the BrowserView to apply the dark toolbar theme.
Instead, this change updates ProfileMenu expectations to support the CEF
incognito profiles without otherwise modifying the incognito behavior.
Note that the IsIncognitoProfile() implementation has recently changed in
https://crrev.com/7bf6eb2497 and the conclusions in this commit will likely need
to be revisited in an upcoming Chromium update.
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 server thread was not guaranteed to be released in the correct scope on
CEF shutdown. This resulted in occasional thread_restrictions assertions on
ceftests shutdown after running the URLRequestTest suite with the Chrome
runtime enabled.
Marshall Greenblatt