Commit Graph

10 Commits

Author SHA1 Message Date
Marshall Greenblatt
25c75c5fc4 Use new PrintViewManagerBase::PrintToPdf method (fixes issue #3377) 2022-10-14 14:10:30 -04:00
Marshall Greenblatt
35654cd709 alloy: Use Chrome JS dialogs on Windows/Linux (fixes issue #3316) 2022-06-03 22:45:23 +03:00
Marshall Greenblatt
7a372a642b alloy: Use Views context menus on Windows/Linux (fixes issue #3330) 2022-05-20 14:15:17 +03:00
Marshall Greenblatt
c04895b222 chrome: Implement GetWindowHandle() for --multi-threaded-message-loop (see issue #3294) 2022-04-19 18:52:26 -04:00
Marshall Greenblatt
3000bc8748 chrome: win/linux: Add support for browser with native parent (see issue #3294)
This change adds Chrome runtime support on Windows and Linux for creating a
browser parented to a native window supplied by the client application.
Expected API usage and window behavior is similar to what already exists with
the Alloy runtime. The parent window handle should be specified by using
CefWindowInfo::SetAsChild in combination with the CefBrowserHost::CreateBrowser
and CefLifeSpanHandler::OnBeforePopup callbacks.

The previously existing behavior of creating a fully-featured Chrome browser
window when empty CefWindowInfo is used with CreateBrowser remains unchanged
and Views is still the preferred API for creating top-level Chrome windows
with custom styling (e.g. title bar only, frameless, etc).

The cefclient Popup Window test with a native parent window continues to crash
on Linux with both the Alloy and Chrome runtimes (see issue #3165).

Also adds Chrome runtime support for CefDisplayHandler::OnCursorChange.

To test:
- Run `cefclient --enable-chrome-runtime [--use-views]` for the default (and
  previously existing) Views-based behavior.
- Run `cefclient --enable-chrome-runtime --use-native` for the new native
  parent window behavior.
- Run `cefclient --enable-chrome-runtime --use-native --no-activate` and the
  window will not be activated (take input focus) on launch (Windows only).
- Run `cefclient --enable-chrome-runtime [--use-views|--use-native]
  --mouse-cursor-change-disabled` and the mouse cursor will not change on
  mouseover of DOM elements.
2022-04-12 11:49:26 -04:00
Marshall Greenblatt
8733cb89c7 chrome: Add Views API integration (see issue #2969)
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.
2021-02-21 15:25:10 -05:00
Marshall Greenblatt
4fbd247231 Add chrome runtime support for more callbacks and ceftests (see issue #2969)
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.*
2020-09-29 18:31:43 -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
02cdf05848 Move Alloy-specific logic to CefBrowserPlatformDelegateAlloy (see issue #2969)
Also remove OSR-related methods where the attributes can instead be passed
to the OSR platform delegate constructor directly.
2020-07-04 16:13:30 -04:00
Marshall Greenblatt
e9bf3cdb98 Add initial Chrome runtime support for browser APIs (see issue #2969)
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.
2020-07-04 16:13:30 -04:00