Commit Graph

11 Commits

Author SHA1 Message Date
Marshall Greenblatt e94a261bf5 Rename CefBrowserHostImpl to AlloyBrowserHostImpl (see issue #2969)
After commit 38d8acfa18 this object is only used with the alloy runtime.
2020-09-22 17:36:06 -04:00
Marshall Greenblatt 38d8acfa18 Create a ChromeBrowserHostImpl for every Chrome tab (see issue #2969)
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.
2020-09-21 17:06:56 -04:00
Marshall Greenblatt 84f3ff2afd Rename the current CEF runtime to Alloy (see issue #2969)
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.
2020-06-29 16:17:41 -04:00
Marshall Greenblatt 241941a44a Move message routing from CefBrowser to CefFrame (see issue #2498).
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.
2019-05-29 17:44:56 +03:00
Marshall Greenblatt 607a1d9f49 Add chrome.tabs.create API support (issue #1947) 2017-09-28 15:41:10 +02:00
Marshall Greenblatt 9cff99dc4e Add support for loading extensions (issue #1947)
- 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.
2017-08-25 18:40:32 -04:00
Marshall Greenblatt b7b145fa4f Update to Chromium revision ad51088c (#444943) 2017-01-24 16:53:09 -05:00
Marshall Greenblatt 211c81cb14 CTRL + left click on a link in a PDF document should call OnOpenURLFromTab (issue #1737) 2015-10-21 17:06:53 -04:00
Marshall Greenblatt 1f21fe5412 Add CefPrintHandler::OnPrintStart callback (issue #1736) 2015-10-13 14:04:02 -04:00
Marshall Greenblatt 4b491c3a77 Fix assertion when loading the PDF extension with begin-frame-scheduling and OSR (issue #1686) 2015-08-17 15:50:04 -04:00
Marshall Greenblatt b7a56d9343 Add PDF extension support (issue #1565) 2015-07-23 14:02:03 -04:00