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.
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>"`
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.
Alexander Guettler
Marshall Greenblatt
Riku Palomäki
Daniel Nitsche
Ananyo Maiti
Petra Öhlin
Riku Palomäki