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.
Chrome currently uses chrome_100_percent.pak, chrome_200_percent.pak,
resources.pak and locales/<locale>.pak files. This change adds CEF
resources to those existing pak files and updates the Alloy runtime to
use them instead of the previous CEF-specific pak files (cef.pak,
cef_100_percent.pak, cef_200_percent.pak, cef_extensions.pak,
devtools_resources.pak) which are no longer generated.
The addition of Chrome resources results in an ~16% (~4.1MB) increase in total
combined pak file size vs. the previous CEF-specific pak files. While a size
increase is not ideal for the Alloy runtime, it seems preferable to the
alternative of distributing separate (and partially duplicated) pak files for
each runtime, which would have added ~9.8MB to the total binary distribution
size.
This fixes an `Unhandled chrome.send("getApps");` error when creating a new tab.
Creating a new tab initially loads chrome://newtab which should then be
rewritten to chrome://new-tab-page for normal profiles in
HandleNewTabURLRewrite. Failure to rewrite the URL results in the loading of
NewTabUI instead of the expected NewTabPageUI. NewTabUI loads different
resources for normal vs incognito/guest profiles (new_tab.js vs
incognito_tab.js), and new_tab.js calls chrome.send("getApps") via
page_list_view.js. This then fails in WebUIImpl::ProcessWebUIMessage because
the message is unhandled.
The Chrome browser can now be hosted in a Views-based application on Mac
(see issue #2969).
To launch a fully-featured Chrome window using cefsimple:
$ open cefsimple.app --args --enable-chrome-runtime
To launch a minimally-styled Views-hosted window using cefsimple:
$ open cefsimple.app --args --use-views [--enable-chrome-runtime]
To launch a fully-styled Views-hosted window using cefclient:
$ open cefclient.app --args --use-views [--enable-chrome-runtime]
Known issues:
- Some Views unit tests are currently failing on Mac.
The Chrome browser can now be hosted in a Views-based application on Windows
and Linux.
To launch a fully-featured Chrome window using cefsimple:
$ cefsimple --enable-chrome-runtime
To launch a minimally-styled Views-hosted window using cefsimple:
$ cefsimple --enable-chrome-runtime --use-views
To launch a fully-styled Views-hosted window using cefclient:
$ cefclient --enable-chrome-runtime --use-views
Views unit tests also now pass with the Chrome runtime enabled:
$ ceftests --gtest_filter=Views* --enable-chrome-runtime
Known issues:
- Popup browsers cannot be intercepted and reparented.
To avoid conflicting IDs between Alloy (which uses cef.pak) and Chrome
(which uses chrome_100_percent.pak) the cef/LICENSE.txt file is now included
in both cef/libcef/resources/cef_resources.grd and
chrome/app/theme/chrome_unscaled_resources.grd with different ID values.
The cef.pak file currently contains both CEF-specific resources and Chrome
resources that are already included in the default *.pak files distributed
with Chrome. In the future we should remove this duplication and just
distribute the same *.pak files as Chrome for the majority of resources.
- Only install network intercepts for Profiles that have an associated
CefBrowserContext. For incognito windows the CefBrowserContext is
associated with the OffTheRecordProfileImpl's original Profile.
- cefsimple: Return the default CefClient instance for browser windows
created via the Chrome UI, and allow Chrome to show error pages.
The cursor change can now be handled by the client with both windowed and
off-screen rendering.
Returning true from OnCursorChange will disable the default cursor change
behavior. This is functionally equivalent to the
CefBrowserHost::SetMouseCursorChangeDisabled method, so that method has been
removed.
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.
The |web_contents_| member was nullptr in CefBrowserPlatformDelegateNativeAura
when calling methods like SendKeyEvent from CefBrowserPlatformDelegateViews.
Media device IDs will now be persisted across navigation and reload by default.
The device IDs will also be persisted across restart if --cache-path=<path> and
--persist-user-preferences settings are specified.
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).
With site-per-process enabled a spare renderer process will be created
for use with a future browser or navigation. Consequently the
|extra_info| parameter populated in OnRenderProcessThreadCreated will no
longer be delivered to OnRenderThreadCreated in the expected renderer
process. To avoid confusion these callbacks have been removed completely.
After this change CefRenderProcessHandler::OnWebKitInitialized should
be used for startup tasks in the render process, and OnBrowserCreated
should be used in the render process to recieve |extra_info| passed from
CefBrowserHost::CreateBrowser or CefLifeSpanHandler::OnBeforePopup.
- 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.
This change moves shared resource initialization to a common location and
disables crash reporting initialization in chrome/ code via patch files.
When using the Chrome runtime on macOS the Chrome application window will
display, but web content is currently blank and the application does not
exit cleanly. This will need to be debugged further in the future.
This change adds basic Chrome runtime implementations for CefBrowserContext
and CefBrowserPlatformDelegate. A Chrome browser window with default frame
and styling can now be created using CefBrowserHost::CreateBrowser and some
CefClient callbacks will be triggered via the WebContentsObserver
implementation in CefBrowserHostImpl.
Any additional browser windows created via the Chrome UI will be unmanaged
by CEF. The application message loop will block until all browser windows
have been closed by the user.
This change moves the runtime-specific implementations of CefBrowserHostImpl
methods to CefBrowserPlatformDelegate. Some WebContentsDelegate methods
implemented by CefBrowserHostImpl set state or trigger client callbacks.
Those implementations will likely stay with CefBrowserHostImpl and will
need to be called from the Browser equivalents when using the Chrome runtime.
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.
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
CefContext implements the public CEF API functions and delegates
the stages of content & service_manager process execution to
CefMainRunner. CEF-specific runtime logic (which may be replaced
with chrome-specific runtime logic) is then delegated to
CefMainDelegate which implements content::ContentMainDelegate.
This change allows the client to directly send and receive DevTools
protocol messages (send method calls, and receive method results and
events) without requiring a DevTools front-end or remote-debugging
session.
This change includes additional supporting changes:
- Add a new CefRequestHandler::OnDocumentAvailableInMainFrame
callback (see issue #1454).
- Add a CefParseJSON variant that accepts a UTF8-encoded buffer.
- Add a `--devtools-protocol-log-file=<path>` command-line flag for
logging protocol messages sent to/from the DevTools front-end
while it is displayed. This is useful for understanding existing
DevTools protocol usage.
- Add a new "libcef_static_unittests" executable target to support
light-weight unit tests of libcef_static internals (e.g. without
requiring exposure via the CEF API). Files to be unittested are
placed in the new "libcef_static_unittested" source_set which is
then included by both the existing libcef_static library and the
new unittests executable target.
- Linux: Remove use_bundled_fontconfig=false, which is no longer
required and causes unittest build errors (see issue #2424).
This change also adds a cefclient demo for configuring offline mode
using the DevTools protocol (fixes issue #245). This is controlled
by the "Offline mode" context menu option and the `--offline`
command-line switch which will launch cefclient in offline mode. When
cefclient is offline all network requests will fail with
ERR_INTERNET_DISCONNECTED and navigator.onLine will return false when
called from JavaScript in any frame. This mode is per-browser so
newly created browser windows will have the default mode. Note that
configuring offline mode in this way will not update the Network tab
UI ("Throtting" option) in a displayed DevTools front-end instance.
This attribute is useful for identifying different classes of cast devices
without first requiring a connection (CAST, CAST_AUDIO, CAST_AUDIO_GROUP, etc).
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.
The PDF extension will send Range requests when loading large PDF files. For
these cross-origin requests to be allowed (from extension origin to PDF origin)
the CORB checks in URLLoader must be disabled.
This restores the behavior prior to revision 438382c. Calling
InitializeSandboxInfo from inside libcef won’t work unless libcef is
statically linked with the executable, so there's no point in doing so.
See the Chromium sandbox docs for background.
If a cache_path is specified local_state will now be persisted to a
LocalPrefs.json file. This is necessary because local_state is used to store
the cookie encryption key on Windows.
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.
Chromium supports communication with media devices on the local network via
the Cast and DIAL protocols. This takes two primary forms:
1. Messaging, where strings representing state information are passed between
the client and a dedicated receiver app on the media device. The receiver
app communicates directly with an app-specific backend service to retrieve
and possibly control media playback.
2. Tab/desktop mirroring, where the media contents are streamed directly from
the browser to a generic streaming app on the media device and playback is
controlled by the browser.
This change adds support for device discovery and messaging (but not
mirroring) with functionality exposed via the new CefMediaRouter interface.
To test: Navigate to http://tests/media_router in cefclient and follow the
on-screen instructions.
This includes the following changes:
- Update usage of surface IDs to match the Aura implementation from the
RWHVAura/Window classes.
- Batch CefBrowserHost::WasResized calls to avoid excessive/unnecessary calls
to SynchronizeVisualProperties.
- Cache the results of CefRenderHandler::GetViewRect after resize and make
RWHVOSR::GetViewBounds the source of truth for all size calculations.
- Fix bounds calculations in CefVideoConsumerOSR with GPU enabled.
Known issues:
- The size passed to OnPaint may be off by 1 pixel in cases where the device
scale factor is not 1 and does not divide evenly into the pixel size. This is
due to the inexact conversion from integer pixel size to integer logical size
for GetViewRect.
Call DesktopWindowTreeHostPlatform::Close after destroying CEF's X11 window
so that objects owned by the WindowTreeHost (Compositor, X11Window, etc) are
properly cleaned up.
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).
Mouse events need to be routed to the correct view and
CefRenderWidgetHostViewOSR::TransformPointToCoordSpaceForView needs to be
properly implemented for
RenderWidgetHostInputEventRouter::DispatchTouchscreenGestureEvent to
transform event position in the target widget.
As of https://crrev.com/9e653328e3 the Views framework will apply the "always
on top" (WS_EX_TOPMOST) style by default to widgets created with TYPE_MENU. CEF
uses this type in CefWindowView::CreateWidget to support child windows that are
not clipped to the parent window bounds (currently indicated by returning a
parent window from CefWindowDelegate::GetParentWindow and setting |is_menu| to
true).
Not setting "always on top" shouldn't be a problem except in cases where some
other window is already "always on top" and the child CefWindow is expected to
overlay that window. For this reason any menus created using ShowMenu will
continue to have the "always on top" style.
This restores the default site isolation mode for Chromium on desktop
platforms. Unit tests have been updated to reflect the new behavior
expectations.
Known behavior changes in CEF are as follows:
- A spare renderer process may be created on initial browser creation or cross-
origin navigation. This spare process may be used with a future cross-origin
navigation or discarded on application shutdown. As a result
CefRenderProcessHandler::OnRenderThreadCreated, which is called shortly after
renderer process creation, can no longer be used to reliably transfer state
for the currently in-progress navigation. Unit tests have been updated to use
the CreateBrowser/OnBeforePopup |extra_info| value for transferring test state
to CefRenderProcessHandler::OnBrowserCreated which will be called in the
correct/expected renderer process.
- Cross-origin navigations will again receive a new renderer process, as
expected. This behavior had briefly regressed in M78 due to the
ProcessSharingWithDefaultSiteInstances feature becoming enabled by default.
- Cross-origin navigations initiated by calling LoadURL in the renderer process
will now crash that process with "bad IPC message" reason
INVALID_INITIATOR_ORIGIN (213). This is a security feature implemented in
Chromium.
- A DevTools browser created using CefBrowserHost::ShowDevTools will receive
the same CefRenderProcessHandler::OnBrowserCreated |extra_info| value that was
set via CreateBrowser/OnBeforePopup for the parent browser.
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.
Remove the local thread object in favor of setting the ui_thread_ field
directly. This avoids the race between ui_thread_.swap(thread) and
CefUIThread::InitializeBrowserRunner.
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.
This change adds a new CefSettings.root_cache_path value that must be either
equal to or a parent directory of all CefSettings.cache_path and
CefRequestContextSettings.cache_path values. The sandbox may block read/write
access from the NetworkService to directories that do not meet this requirement.
To test: Run cefclient with a combination of the following flags:
--cache-path=c:\temp\cache
Cache data should be persisted to the specified directory.
--request-context-per-browser
A separate numbered cache directory should be created underneath the
cache-path directory for each new browser instance.
--enable-network-service --disable-extensions
Same tests, but with NetworkService enabled.
Known issues:
- When NetworkService is enabled a C:\temp\cache\cache\Cache directory is
created (should be C:\temp\cache\Cache).
A CefBrowserHostImpl is created using a CefRequestContextImpl that may have a
CefRequestContextHandler. Multiple CefRequestContextImpl may share the same
underlying CefBrowserContext which owns a CefResourceContext. IO-thread
callbacks from Chromium are often associated with a CefResourceContext and the
target frame is identified using render_process_id/render_frame_id routing IDs.
This change forwards frame create/delete notifications from CefBrowserHostImpl
(or CefMimeHandlerViewGuestDelegate) to CefResourceContext so that it can
properly resolve the association from routing ID to Handler when queried from
CefPluginServiceFilter::IsPluginAvailable.
To test: Verify that all ceftests pass with NetworkService disabled.
This change removes cookie and request handler functionality that will not
supported by the NetworkService. Specifically, it is no longer possible to
change cookie storage locations at runime by returning a different
CefCookieManager for an already initialized CefRequestContext. After this change
you will need to use a separate CefRequestContext when creating a CefBrowser if
you require separate cookie storage.
The following methods have been removed:
- CefCookieManager::CreateManager
- CefCookieManager::GetBlockingManager
- CefCookieManager::SetStoragePath
- CefRequestContextHandler::GetCookieManager
The following methods have been renamed:
- CefRequestContext::GetDefaultCookieManager to GetCookieManager.
This change substantially simplifies the network implementation in CEF because
it is no longer necessary to proxy objects that are normally owned by Chromium.
Chromium patches that are no longer necessary will be removed as a follow-up
commit.
To test: Verify that `ceftests --gtest_filter=-PluginTest.*` pass with
NetworkService disabled. Plugin tests will be fixed in a follow-up commit.
This change adds an --enable-network-service command-line flag to run with
NetworkService enabled.
To test: Run `cefclient --enable-network-service --disable-extensions`. The
application should start, load a website and exit without crashing.
Network-related handlers (for cookies, schemes, requests, etc) and extensions
are not expected to work yet.
There should be no functional change when running without the NetworkService
enabled.
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.
