GitLab

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}