RemoteMacViews: Allow for BridgedNativeWidget to create its own NSWindow
Because BridgedNativeWidget will be living in its own process, it will be necessary for BridgedNativeWidget to create its own NSWindow, instead of having one be provided during initialization. This requires substantial refactoring, and two of the NSWindow classes that BridgedNativeWidget are provided live in chrome/browser/ui, and will need moving to a new location. For the moment, allow either creating a new NSWindow or specifying an NSWindow via the methods BridgedNativeWidget::CreateWindow and BridgedNativeWidget::SetWindow. This unblocks cross-process development. Also, be explicit that BridgedNativeWidget's NSWindow is always a NativeWidgetMacNSWindow or a sub-class thereof. The only exceptions to this are in tests, so merge testing functionality into NativeWidgetMacNSWindow. Bug: 859152 Change-Id: I61edb34d773fc11dff921da5edb34da1e306105b Reviewed-on: https://chromium-review.googlesource.com/1175051 Commit-Queue: ccameron <ccameron@chromium.org> Reviewed-by:Elly Fong-Jones <ellyjones@chromium.org> Cr-Commit-Position: refs/heads/master@{#583350}
Showing
This diff is collapsed.
Please register or sign in to comment