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.
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.
- 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 a minimal implementation of the |tabs.update| extension API and
modifies StreamsPrivateAPI::SendExecuteMimeTypeHandlerEvent to return a valid
|streamInfo.tabId| value as required by the navigateInCurrentTab implementation
in chrome/browser/resources/pdf/browser_api.js.
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.
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 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.