chrome: Add support for embedded non-Views windows

[magreenblatt]

Original report by me.

---

This issue involves the following functionality currently supported by the Alloy runtime:

• Embedded non-Views windows (where the host application creates the top-level window), created with CefWindowInfo.SetAsChild.

See issue ~~#2969~~ for background on the Chrome runtime.

‌

[magreenblatt]

Original comment by Dominik Mayrhofer-Poldlehner (Bitbucket: dmayrhofer, GitHub: dmayrhofer).

---

Would it be possible to embed CEF windows into Wayland windows with this feature?

[magreenblatt]

Would it be possible to embed CEF windows into Wayland windows with this feature?

This would likely require the Ozone implementation from issue #3263. Basically, the CEF window contents need to become a sub-surface in Wayland because embedding of “windows” on Wayland is generally not supported (based on what I can find, example here).

[magreenblatt]

Issue #3289 was marked as a duplicate of this issue.

[magreenblatt]

See issue #2804 for embedded Wayland support specifically.

[magreenblatt]

Fix dismissal of select popups on NotifyMoveOrResizeStarted (see issue #3294)

This impacts both Alloy and Chrome runtimes when using a native parent window.

→ <<cset 5f4bccd672c1 (bb)>>

[magreenblatt]

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.

→ <<cset 3000bc8748d8 (bb)>>

[magreenblatt]

cefclient: Add option to create default popups (see issue #3165, see issue #3294)

This change adds a --use-default-popup command-line option to cefclient. When specified, popup windows will be created with default styling (e.g. without an application-provided native parent window).

This change also adds some reasonable default window bounds in cases where they are not specified by the client.

→ <<cset 75ca552a4e88 (bb)>>

[magreenblatt]

chrome: Change popup default behavior with native parent (see issue #3294)

When using a Views-hosted browser window the client receives Views-related callbacks for popups and can thereby customize the Views-hosted popup behavior. When using an external parent window no Views-related callbacks are delivered and customization options are restricted to providing a new parent handle via OnBeforePopup. Consequently, we should default to a normal browser window in the external parent case instead of the very minimial Views-hosted default.

To test (A):

1. Run cefclient --use-default-popup --enable-chrome-runtime --use-native
2. Select Tests > Popup Window
3. Get a normal Chrome browser window

To test (B):

1. Run cefclient --use-default-popup [--enable-chrome-runtime] [--use-views]
2. Select Tests > Popup Window
3. Get a native or Views-hosted browser window with title bar only

→ <<cset a0a7a35fe2d1 (bb)>>

[magreenblatt]

Fix dismissal of select popups on NotifyMoveOrResizeStarted (see issue #3294)

This impacts both Alloy and Chrome runtimes when using a native parent window.

→ <<cset c3a6788f6ea1 (bb)>>

[magreenblatt]

Fix dismissal of select popups on NotifyMoveOrResizeStarted (see issue #3294)

This impacts both Alloy and Chrome runtimes when using a native parent window.

→ <<cset 579536b10703 (bb)>>

[magreenblatt]

Popups are not placed correctly when running --enable-chrome-runtime --use-native --multi-threaded-message-loop.

1. Load http://tests/dialogs
2. Click a button (user action required for the onunload dialog)
3. Close the window.
4. Notice that the dialog prompt is way off to the right-hand side of the window.

‌

[magreenblatt]

I’m not exactly sure how this will work on MacOS. The current CEF API expects CefWindowInfo to be an NSView and, with Chrome, we might need to operate on an NSWindow.

(The following discussion is based on this overview of the Chrome Browser object model.)

Chrome’s NativeWidgetMac uses NativeWidgetMacNSWindowHost to communicate with an NSWindow that may be hosted in a separate process (see https://crbug.com/893719). We can currently get a gfx::NativeWindow (wrapper of NSWindow*) representation via browser->browser_window()->GetNativeWindow(). However, we can’t necessarily extract an NSView from that for parenting to a client-provided NSWindow (retrieving the Chrome NSWindow’s contentView works, but reparenting that to a different NSWindow might cause undefined behavior).

One possible approach might be using a “placeholder” NSView to locate the browser in the client’s NSWindow layout. We could then use addChildWindow to position the Chrome NSWindow on top of that “placeholder”.

[magreenblatt]

chrome: Implement GetWindowHandle() for --multi-threaded-message-loop (see issue #3294)

→ <<cset c04895b22263 (bb)>>

[magreenblatt]

Once we figure out the above MacOS complications we should consider moving the Alloy implementation to Views as well. We can then share the Chrome Views implementations for context menus, dialogs, etc.

[magreenblatt]

Original comment by Laurenz Bihlmayer (Bitbucket: Laurenz Bihlmayer).

---

Good to see that Wayland support is being worked on, at least slowly :)

Just a quick question from a CEF noob:
If this was resolved, would this allow applications like Spotify or Steam to finally support Wayland natively (if they update their CEF version)?
Or do they already use Views and don’t have their own top-level window?

And what’s the relationship of this issue and #2804? They seem to deal with pretty similiar topics.

[magreenblatt]

@{557058:42b4c7e0-11f8-412d-8c8e-91e4a9d47d4e} See the comment here which addresses your questions.

[magreenblatt]

Revert "Fix dismissal of select popups on NotifyMoveOrResizeStarted (see issue #3294)"

This reverts commit 5f4bccd672c1ed745218a9d756e430f0164fd3ba (bb).

Reason for revert: This change causes a native parented browser to lose focus on move (fixes issue #3426).

→ <<cset b66c2d1bea43 (bb)>>

[magreenblatt]

Revert "Fix dismissal of select popups on NotifyMoveOrResizeStarted (see issue #3294)"

This reverts commit 5f4bccd672c1ed745218a9d756e430f0164fd3ba (bb).

Reason for revert: This change causes a native parented browser to lose focus on move (fixes issue #3426).

→ <<cset 2567ca15a9a2 (bb)>>

[magreenblatt]

Revert "Fix dismissal of select popups on NotifyMoveOrResizeStarted (see issue #3294)"

This reverts commit 5f4bccd672c1ed745218a9d756e430f0164fd3ba (bb).

Reason for revert: This change causes a native parented browser to lose focus on move (fixes issue #3426).

→ <<cset c81ef733d9ea (bb)>>

[magreenblatt]

Original comment by Michael S (Bitbucket: Michael S).

---

@{557058:2f2a2aee-b500-4023-9734-037e9897c3ab}

Does this issue need to be implemented before a Windows application can use Chrome extensions? I am very interested in using Chrome extensions in my CefSharp application.

[magreenblatt]

Does this issue need to be implemented before a Windows application can use Chrome extensions? I am very interested in using Chrome extensions in my CefSharp application.

The Windows implementation for this issue is already complete. Using the Chrome runtime in required for extension support. I can’t speak to if or when the Chrome runtime will be supported by CefSharp.

[magreenblatt]

Original comment by Michael S (Bitbucket: Michael S).

---

@Marshall Greenblatt Excellent! Thanks for the quick response. I’ll take it up with the CefSharp team.

[magreenblatt]

Support for DevTools popups with native parent was added in #3600.

[magreenblatt]

This is fully supported (all platforms) with Alloy style. See #3681.