This change adds support for:
- Protocol and request handling.
- Loading and navigation events.
- Display and focus events.
- Mouse/keyboard events.
- Popup browsers.
- Callbacks in the renderer process.
- Misc. functionality required for ceftests.
This change also adds a new CefBrowserProcessHandler::GetCookieableSchemes
callback for configuring global state that will be applied to all
CefCookieManagers by default. This global callback is currently required by the
chrome runtime because the primary ProfileImpl is created via
ChromeBrowserMainParts::PreMainMessageLoopRun (CreatePrimaryProfile) before
OnContextCreated can be called.
ProfileImpl will use the "C:\Users\[user]\AppData\Local\CEF\User Data\Default"
directory by default (on Windows). Cookies may persist in this directory when
running ceftests and may need to be manually deleted if those tests fail.
Remaining work includes:
- Support for client-created request contexts.
- Embedding the browser in a Views hierarchy (cefclient support).
- TryCloseBrowser and DoClose support.
- Most of the CefSettings configuration.
- DevTools protocol and window control (ShowDevTools, ExecuteDevToolsMethod).
- CEF-specific WebUI pages (about, license, webui-hosts).
- Context menu customization (CefContextMenuHandler).
- Auto resize (SetAutoResizeEnabled).
- Zoom settings (SetZoomLevel).
- File dialog runner (RunFileDialog).
- File and JS dialog handlers (CefDialogHandler, CefJSDialogHandler).
- Extension loading (LoadExtension, etc).
- Plugin loading (OnBeforePluginLoad).
- Widevine loading (CefRegisterWidevineCdm).
- PDF and print preview does not display.
- Crash reporting is untested.
- Mac: Web content loads but does not display.
The following ceftests are now passing when run with the
"--enable-chrome-runtime" command-line flag:
CorsTest.*
DisplayTest.*:-DisplayTest.AutoResize
DOMTest.*
DraggableRegionsTest.*
ImageTest.*
MessageRouterTest.*
NavigationTest.*
ParserTest.*
RequestContextTest.*Global*
RequestTest.*
ResourceManagerTest.*
ResourceRequestHandlerTest.*
ResponseTest.*
SchemeHandlerTest.*
ServerTest.*
StreamResourceHandlerTest.*
StreamTest.*
StringTest.*
TaskTest.*
TestServerTest.*
ThreadTest.*
URLRequestTest.*Global*
V8Test.*:-V8Test.OnUncaughtExceptionDevTools
ValuesTest.*
WaitableEventTest.*
XmlReaderTest.*
ZipReaderTest.*
The Browser object represents the top-level Chrome browser window. One or more
tabs (WebContents) are then owned by the Browser object via TabStripModel. A
new Browser object can be created programmatically using "new Browser" or
Browser::Create, or as a result of user action such as dragging a tab out of an
existing window. New or existing tabs can also be added to an already existing
Browser object.
The Browser object acts as the WebContentsDelegate for all attached tabs. CEF
integration requires WebContentsDelegate callbacks and notification of tab
attach/detach. To support this integration we add a cef::BrowserDelegate
(ChromeBrowserDelegate) member that is created in the Browser constructor and
receives delegation for the Browser callbacks. ChromeBrowserDelegate creates a
new ChromeBrowserHostImpl when a tab is added to a Browser for the first time,
and that ChromeBrowserHostImpl continues to exist until the tab's WebContents
is destroyed. The associated WebContents object does not change, but the
Browser object will change when the tab is dragged between windows.
CEF callback logic is shared between the chrome and alloy runtimes where
possible. This shared logic has been extracted from CefBrowserHostImpl to
create new CefBrowserHostBase and CefBrowserContentsDelegate classes. The
CefBrowserHostImpl class is now only used with the alloy runtime and will be
renamed to AlloyBrowserHostImpl in a future commit.
A CORS preflight request is an "OPTIONS" request sent to a server prior to a
cross-origin XMLHttpRequest or Fetch request. The server's response determines
which HTTP request methods are allowed and supported, and whether credentials
such as Cookies and HTTP Authentication should be sent with requests.
A CORS preflight request will only be sent if certain conditions are met. For
example, it will be sent for requests that have potentially unsafe HTTP
methods [1] or request headers [2]. See the NeedsPreflight function in
services/network/cors/cors_url_loader.cc for full details.
CORS preflight functionality is implemented in the network service and will not
be triggered if the client handles the request instead of allowing it to proceed
over the network. Since the preflight request itself also runs in the network
service it cannot be intercepted by the client.
[1] https://fetch.spec.whatwg.org/#cors-safelisted-method
[2] https://fetch.spec.whatwg.org/#cors-safelisted-request-header
The request.trusted_params.isolation_info.site_for_cookies value must
match request.site_for_cookies.
This change also adds unit test coverage for cross-origin GET redirects.
This fixes an IsCanonical() DCHECK failure triggered by calling
CanonicalCookie::Create for a non-cookieable URL.
This change also adds unit test coverage for cross-origin cookie
behavior with sub-resource requests (iframe, XHR, Fetch).
- CefURLRequest::Create is no longer supported in the renderer process
(see https://crbug.com/891872). Use CefFrame::CreateURLRequest instead.
- Mac platform definitions have been changed from `MACOSX` to `MAC`
(see https://crbug.com/1105907) and related CMake macro names have
been updated. The old `OS_MACOSX` define is still set in code and CMake
for backwards compatibility.
- Linux ARM build is currently broken (see https://crbug.com/1123214).
- Windows: 10.0.19041 SDK is now required.
- macOS: 10.15.1 SDK (at least Xcode 11.2) is now required.
- Remove CefMediaSource::IsValid and CefMediaSink::IsValid which would
always return true.
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.
This is the first pass in removing direct dependencies on the Alloy
runtime from code that can potentially be shared between runtimes.
CefBrowserHost and CefRequestContext APIs (including CefCookieManager,
CefURLRequest, etc.) are not yet implemented for the Chrome runtime.
Assert early if these API methods are called while the Chrome runtime
is enabled.
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.
This change also restores the Chromium default values for the
SameSiteByDefaultCookies and CookiesWithoutSameSiteMustBeSecure features. See
https://www.chromium.org/updates/same-site for feature details and rollout
timeline.
With this change CefCookieManagerImpl no longer keeps a reference to the
originating CefRequestContextImpl. This means that the CefRequestContextImpl
can be destroyed if all other references are released while the
CefCookieManagerImpl exists. If CefRequestContextImpl destruction results in
the underlying CefBrowserContext being destroyed then the CefCookieManagerImpl's
reference to that CefBrowserContext will be invalidated.
This is the same ownership model introduced with CefMediaRouterImpl in the
previous commit.
Requests from the PDF viewer are not associated with a CefBrowser. Consequently,
the InterceptedRequestHandler for those requests will register as an observer of
CefContext destruction. When the browser is closed the InterceptedRequestHandler
is destroyed and an async task is posted to remove/delete the observer on the UI
thread. If CefShutdown is then called the task may execute after shutdown has
started, in which case CONTEXT_STATE_VALID() will return false. We still need to
remove the observer in this case to avoid a use-after-free in
FinishShutdownOnUIThread.
Modifying the URL in OnBeforeResourceLoad causes an internal redirect response.
In cases where the request is cross-origin and credentials mode is 'include'
the redirect response must include the "Access-Control-Allow-Credentials"
header, otherwise the request will be blocked.
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.
For 303 redirects all request methods except HEAD are converted to GET as per
the latest http draft. For historical reasons the draft also allows POST
requests to be converted to GETs when following 301/302 redirects. Most major
browsers do this and so shall we. When a request is converted to GET any POST
data should also be removed.
Use 307 redirects instead if you want the request to be repeated using the same
method and POST data.
Modifying the URL in OnBeforeResourceLoad causes an internal redirect response.
In cases where the request is cross-origin (containing a non-null "Origin"
header) the redirect response must include the "Access-Control-Allow-Origin"
header, otherwise the request will be blocked.
This change also fixes a problem where existing request headers would be
discarded if the request was modified in OnBeforeResourceLoad.
Initialization of request objects requires asynchronous hops between the UI and
IO threads. In some cases the browser may be destroyed, the mojo connection may
be aborted, or the ProxyURLLoaderFactory object may be deleted while
initialization is still in progress. This change fixes crashes and adds unit
tests that try to reproduce these conditions.
To test: Run `ceftests --gtest_repeat=50
--gtest_filter=ResourceRequestHandlerTest.Basic*Abort*`
This is a speculative fix for a crash where |on_disconnect_| appears to be null
in ProxyURLLoaderFactory::MaybeDestroySelf. The hypothesis here is that
OnURLLoaderClientError is being called while the proxy object is still in-flight
to ResourceContextData::AddProxy (e.g. before SetDisconnectCallback has been
called for the proxy object). Additonally, this change protects against
MaybeDestroySelf attempting to execute |on_disconnect_| multiple times.
Marshall Greenblatt
Cristian Amarie
Alexander Guettler
Dmitry Azaraev
Jengerer
Yong Li
Daniel Nitsche
Masako Toda
Petra Öhlin