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).
Marshall Greenblatt
Corentin Dumont
Yannick
Dmitry Azaraev
Cristian Amarie
Masako Toda
Masako Toda
Mike Wiedenbauer