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.
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 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.
- 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.
- Add CefRequestContext::LoadExtension, CefExtension, CefExtensionHandler and
related methods/interfaces.
- Add chrome://extensions-support that lists supported Chrome APIs.
- Add CefBrowserHost::SetAutoResizeEnabled and CefDisplayHandler::OnAutoResize
to support browser resize based on preferred web contents size.
- views: Add support for custom CefMenuButton popups.
- cefclient: Run with `--load-extension=set_page_color` command-line flag for
an extension loading example. Add `--use-views` on Windows and Linux for an
even better example.
Marshall Greenblatt
Daniel Nitsche
Alexander Guettler