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.
The behavior has changed as follows with NetworkService enabled:
- All pending and in-progress requests will now be aborted when the CEF context
or associated browser is destroyed. The OnResourceLoadComplete callback will
now also be called in this case for in-progress requests that have a handler.
- The CefResourceHandler::Cancel method will now always be called when resource
handling is complete, irrespective of whether handling completed successfully.
- Request callbacks that arrive after the OnBeforeClose callback for the
associated browser (which may happen for in-progress requests that are aborted
on browser destruction) will now always have a non-nullptr CefBrowser
parameter.
- Allow empty parameters to CefRequest and CefResponse methods where it makes
sense (e.g. resetting default response state, or clearing a referrer value).
- Fixed a reference loop that was keeping CefResourceHandler objects from being
destroyed if they were holding a callback reference (from ProcessRequest,
ReadResponse, etc.) during CEF context or associated browser destruction.
- Fixed an issue where the main frame was not detached on browser destruction
which could cause a crash due to RFH use-after-free (see issue #2498).
To test: All unit tests pass as expected.
This change fixes an issue where the cancel_callback for a pending request
might already have been executed when the OnBrowserDestroyed notification is
received.
This change moves the SendProcessMessage method from CefBrowser to CefFrame and
adds CefBrowser parameters to OnProcessMessageReceived and
OnDraggableRegionsChanged.
The internal implementation has changed as follows:
- Frame IDs are now a 64-bit combination of the 32-bit render_process_id and
render_routing_id values that uniquely identify a RenderFrameHost (RFH).
- CefFrameHostImpl objects are now managed by CefBrowserInfo with life span tied
to RFH expectations. Specifically, a CefFrameHostImpl object representing a
sub-frame will be created when a RenderFrame is created in the renderer
process and detached when the associated RenderFrame is deleted or the
renderer process in which it runs has died.
- The CefFrameHostImpl object representing the main frame will always be valid
but the underlying RFH (and associated frame ID) may change over time as a
result of cross-origin navigations. Despite these changes calling LoadURL on
the main frame object in the browser process will always navigate as expected.
- Speculative RFHs, which may be created as a result of a cross-origin
navigation and discarded if that navigation is not committed, are now handled
correctly (e.g. ignored in most cases until they're committed).
- It is less likely, but still possible, to receive a CefFrame object with an
invalid frame ID (ID < 0). This can happen in cases where a RFH has not yet
been created for a sub-frame. For example, when OnBeforeBrowse is called
before initiating navigation in a previously nonexisting sub-frame.
To test: All tests pass with NetworkService enabled and disabled.
This adds support for the CloseAllConnections and ResolveHost methods.
To test: RequestContextTest.Close* and RequestContextTest.Resolve* tests pass
with NetworkService enabled.
Always return ERR_NONE and the response body if a CefURLRequest completes
successfully, including for non-2xx status codes. This matches the behavior of
the old network stack.
To test: ServerTest.* tests pass with NetworkService enabled.
Pending requests that are associated with a browser will be canceled when that
browser is destroyed. Pending requests that are not associated with a browser
(e.g. created using CefURLRequest::Create), and that use the global context, may
still be pending when CefShutdown is called. For this reason the
no_debugct_check attribute has been added for CefResourceRequestHandler and
CefCookieAccessFilter interfaces.
To test: Load a YouTube video or other long-loading content in cefclient and
close the application. No assertions trigger for leaked CefFrame objects.
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.
The optional |extra_info| parameter provides an opportunity to specify extra
information specific to the created browser that will be passed to
CefRenderProcessHandler::OnBrowserCreated() in the render process.
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.
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.
Known behavior changes:
- Unsupported chrome hosts no longer redirect to chrome://version.
To test: All tests pass with NetworkService disabled. WebUITest.* and V8Test.*
tests pass with NetworkService enabled.
When using multi-threaded message loop mode the PrefService needs to be created
on the UI thread.
To test: Run `cefclient --enable-network-service --multi-threaded-message-loop`.
The application should start successfully.
This change fixes a load hang when no custom handlers (CefResourceRequestHandler
or registered scheme handler) are found for a request.
To test: Run `cefsimple --enable-network-service` and all requests load. Test
expectations are unchanged.
This change allows the NetworkService to handle cookie load/save in cases where
cookies will not be filtered (CefResourceRequestHandler::GetCookieAccessFilter
returns null) and the request will be handled by the default network loader.
This represents a minor performance improvement by reducing the volume of cross-
process messaging in the default (no filtering or custom handing) case. Cookie
load/save still needs to be routed through the browser process if a filter is
returned, or if a CefResourceHandler is used for the request.
To test: Test expectations are unchanged.
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.*
Under ARC (Automatic Reference Counting), assigning to an Objective-C
pointer has different semantics than assigning to a void* pointer.
This makes it dangerous to treat the same memory address as an
Objective-C pointer in some cases and as a "regular C pointer" in
other cases.
This change removes the conditional type defines and instead uses
void* everywhere. Explicit type casting in combination with ARC
annotations makes it safe to get typed Objective-C pointers from the
void* pointers.
This change enables ARC by default in the CEF binary distribution CMake
configuration for the cefclient and cefsimple sample applications. It can be
disabled by adding `-DOPTION_USE_ARC=Off` to the CMake command line.
ARC is not supported when building Chromium due to the substantial
number of changes that would be required in the Chromium code base.
Ozone builds can run with different platform backends (Wayland, X11, etc). Usage of the Views framework is required, and the cefclient sample application is not supported.
Example usage:
$ export GN_DEFINES="use_ozone=true"
$ cd /path/to/chromium/src/cef
$ ./cef_create_projects.sh
$ cd /path/to/chromium/src
$ ninja -C out/Release_GN_x64 cefsimple
$ ./out/Release_GN_x64/cefsimple --use-views --ozone-platform=wayland
Binary distributions can be created by passing the `--ozone` flag to make_distrib.py.
We don't support the WebRequestAPI yet, so we shouldn't be creating any objects
for it.
To test: Run `cefclient --enable-network-service` and then close the app.
The Chromium content layer (which also exposes the NetworkService interface)
generally runs on the UI thread. Previous use of the IO thread for CookieManager
callbacks is an implementation detail of the old network stack that shouldn't be
exposed to clients.
To test: Run ceftests. They should pass as expected.
To test: Run `ceftests --gtest_filter=CookieTest.*:-CookieTest.GetCookieManager*
--enable-network-service`
There should be no functional change when running without the NetworkService
enabled.
Known issues:
- CefCookieManager::SetSupportedSchemes is not yet implemented.
Marshall Greenblatt
Alexander Guettler
Petra Öhlin
Andrei Kurushin
cef-ms
Chris Dziemborowicz
Ananyo Maiti
Jesper Papmehl-Dufay
santosh mahto
Daniel Nitsche
Riku Palomäki
Orfeas Zafeiris