Existing CefBrowserContext functionality is now split between
CefBrowserContext and AlloyBrowserContext. Runtime implementations of
CefBrowserContext will provide access to the content::BrowserContext and
Profile types via different inheritance paths. For example, the Alloy
runtime uses ChromeProfileAlloy and the Chrome runtime uses ProfileImpl.
This change also renames CefResourceContext to CefIOThreadState to more
accurately represent its purpose as it no longer needs to extend
content::ResourceContext.
As part of introducing the Chrome runtime we now need to distinguish
between the classes that implement the current CEF runtime and the
classes the implement the shared CEF library/runtime structure and
public API. We choose the name Alloy for the current CEF runtime
because it describes a combination of Chrome and other elements.
Shared CEF library/runtime classes will continue to use the Cef
prefix. Classes that implement the Alloy or Chrome runtime will use
the Alloy or Chrome prefixes respectively. Classes that extend an
existing Chrome-prefixed class will add the Cef or Alloy suffix,
thereby following the existing naming pattern of Chrome-derived
classes.
This change applies the new naming pattern to an initial set of
runtime-related classes. Additional classes/files will be renamed
and moved as the Chrome runtime implementation progresses.
Running `cefsimple --enable-chrome-runtime` will create and run a
Chrome browser window using the CEF app methods, and call
CefApp::OnContextInitialized as expected. CEF task methods also
work as expected in the main process. No browser-related methods or
callbacks are currently supported for the Chrome window, and the
application will exit when the last Chrome window closes.
The Chrome runtime requires resources.pak, chrome_100_percent.pak
and chrome_200_percent.pak files which were not previously built
with CEF. It shares the existing locales pak files which have been
updated to include additional Chrome-specific strings.
On Linux, the Chrome runtime requires GTK so use_gtk=true must be
specified via GN_DEFINES when building.
This change also refactors the CEF runtime, which can be tested in
the various supported modes by running:
$ cefclient
$ cefclient --multi-threaded-message-loop
$ cefclient --external-message-pump
Split `gclient sync` into separate `gclient sync --nohooks` and
`gclient runhooks` steps so that we can optionally apply patches
from `runhooks.patch` in-between. This is necessary because the
src/tools/clang/scripts/update.py script is run via a hook and has
dependencies on the VS toolchain scripts which must be patched to
properly consider the GYP_MSVS_VERSION environment variable.
This works around a bug in the Visual C++ standard library where the
std::is_integral templates are exported instead of inlined when building
with C++14. See also https://bugs.llvm.org/show_bug.cgi?id=42027.
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).
This works around a bug in the Visual C++ standard library where the
std::is_integral templates are exported instead of inlined when building
with C++14. See also https://bugs.llvm.org/show_bug.cgi?id=42027.
Fixes the following error:
In file included from gen/chrome/browser/safe_browsing/safe_browsing_jumbo_1.cc:34:
In file included from ./../../chrome/browser/safe_browsing/download_protection/binary_fcm_service.cc:15:
../../components/gcm_driver/gcm_profile_service.h:18:10: fatal error: 'components/gcm_driver/gcm_buildflags.h' file not found
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.
Requests created using CefURLRequest::Create are not associated with a
browser/frame. When originating from the render process these requests cannot be
intercepted and consequently only http(s) and blob requests are supported. To
work around this limitation a new CefFrame::CreateURLRequest method has been
added that allows the request to be associated with that browser/frame for
interception purposes.
This change also fixes an issue with the NetworkService implementation where
redirected requests could result in two parallel requests being sent to the
target server.
To test: URLRequestTest.* tests pass with NetworkService enabled.
With this change the CefCookieManager::SetSupportedSchemes method can be used
to disable all loading and saving of cookies for the associated request context.
This matches functionality that was previously available via GetBlockingManager.
This change also fixes a bug where Set-Cookie headers returned for a request
handled via CefSchemeHandlerFactory would be ignored if there was not also a
CefResourceRequestHandler returned for the request.
To test: All CookieTest.* tests pass.
To test: When running `cefclient --cache-path=c:\temp\cache` with NetworkService
enabled the the cache directory structure should be "C:\temp\cache\Cache"
instead of "C:\temp\cache\cache\Cache".
When the NetworkService is enabled the U-A string is configured via
SystemNetworkContextManager::CreateDefaultNetworkContextParams, which calls
chrome_content_browser_client.cc GetUserAgent(). This change modifies the Chrome
implementation to match CEF, so that the U-A product component can still be
overridden via the `--product-version` command-line flag.
To test: Verify that chrome://version, navigator.userAgent (JS executed from
DevTools console) and network requests (headers shown in DevTools Network tab)
show the expected User-Agent value in the following cases:
- Running `cefclient --enable-network-service --user-agent="<value>"`
- Running `cefclient --enable-network-service --product-version="<value>"`
To test:
- All tests pass with NetworkService disabled. DownloadTest.*, ExtensionTest.*
and PluginTest.* tests pass with NetworkService enabled.
- The PDF extension displays a file, and the download and print buttons work.
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.*
This adds *.pak, locales/*.pak , chrome-sandbox, libGLESv2.so, libEGL.so and
swiftshader/*.so to the list of binaries that will be loaded from the libcef.so
directory instead of the executable directory by default.
- Windows: 10.0.17763.0 SDK is now required.
- Mac: 10.13 SDK is now required.
- Removed CefRequestContext::ResolveHostCached which is no longer supported by Chromium.
- The |category| value for all TRACE calls from CEF client applications is now
"cef.client" due to https://crrev.com/331266377d.
- The |with_menu_marker| parameter to CreateMenuButton has been removed due to
https://crrev.com/7f7e382118.
- 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.
Known issues:
- The CefLoadCRLSetsFile function needs to be re-implemented (see issue #2497).
- Linux: GTK2 support has been removed. The cefclient sample needs to be updated
to use GTK3 (see issue #2014).
- Add CefRequestContext::LoadExtension, CefExtension, CefExtensionHandler and
related methods/interfaces.
- Add chrome://extensions-support that lists supported Chrome APIs.
- Add CefBrowserHost::SetAutoResizeEnabled and CefDisplayHandler::OnAutoResize
to support browser resize based on preferred web contents size.
- views: Add support for custom CefMenuButton popups.
- cefclient: Run with `--load-extension=set_page_color` command-line flag for
an extension loading example. Add `--use-views` on Windows and Linux for an
even better example.