[macOS] support for embedded non-Views windows

[virwu]

Hi,

I'm trying to implement a fully functional browser based on CEF, and I'm planning to integrate chrome runtime with other UI elements removed into an interface written natively in cocoa, which means I need to add the BrowserView as an NSView to the NSWindow provided by the outer application.

I've been reading up on the progress in https://github.com/chromiumembedded/cef/issues/3294 and am happy to see that this is already supported in windows and linux, as well as your description of a possible macOS implementation.

As you say, the NSWindow provided by Chromium could be from another process, and I've tried adding the NSWindow as a child Window to the main app's NSWindow, but macOS can only have one key window at a time, which makes it impossible for the Chromium window to receive focus at the same time as the app window. window cannot receive focus at the same time, which is unacceptable for a browser.

So I'm trying to offer the app window to chromium as an alternative to the NSWindow it creates itself, in order to integrate the cocoa native view with the web content while preserving chromium capabilities such as extensions.

I realize this is a very difficult task, but is this solution feasible? Or is there a better way to accomplish the above? I hope to get some suggestions from you guys, thanks a lot!

[magreenblatt]

Some alternatives that are currently available on Mac:

• Use the Views framework for UI (supports various controls, layouts, etc)
• Use a single whole-window browser for UI and something like the webview tag for loading external content
• Fork Chromium and modify the /chrome layer as needed to build your app UI (like Edge, Opera, etc)

[magreenblatt]

Looks like the webview tag may no longer be an option. Some additional details from our friends over at Electron: https://www.electronjs.org/docs/latest/api/webview-tag

[virwu]

Thank you very much for the suggestion, it looks like I have to modify the code of the Chromium layer to achieve the capabilities I want.

I have one more question, do you think it's more appropriate to modify based on CEF or fork Chromium directly?

I think that good code wrapping based on CEF allows the application UI layer to be isolated from the browser layer, rather than the application UI layer, which also needs to compile Chromium.

[magreenblatt]

do you think it's more appropriate to modify based on CEF or fork Chromium directly?

It will likely depend on the scope of your Chromium changes, your preferred workflow (patches vs merge/rebase), and your licensing requirements. Chromium contains [L]GPL code (via Blink and third-party libs) so I wouldn’t recommend compiling it into a single binary with proprietary code.

[magreenblatt]

If you’re modifying Chromium you might still consider building your UI using Views (editing /chrome layer files to swap your UI for the default Chrome UI). That will keep you on the Chromium code path for best behavior/performance and have the added benefit of being cross-platform.

[magreenblatt]

There’s a good discussion on patch vs fork in viewtopic.php?f=10&t=17890