fix: send NSView* as the response to getNativeWindowHandle() instead of a null handle

[MarshallOfSound]

Fixes #15489

Notes: Fixed issue where getNativeWindowHandle() would return an empty buffer on macOS

Originally caused by 4068a62 which was caused by https://chromium-review.googlesource.com/c/chromium/src/+/792295

This re-implements the API on macOS without using gfx::AcceleratedWidget

cc @deepak1556

[deepak1556]

Can you add a TODO to restore the old implementation once https://chromium-review.googlesource.com/c/chromium/src/+/1253094/ lands

gfx::AcceleratedWidget NativeWindowMac::GetAcceleratedWidget() const {
  auto* bridged_native_widget = 
      views::BridgedNativeWidgetHostImpl::GetFromNativeWindow(window_);
  return bridged_native_widget->GetRootViewNSViewId();
}

and respective view can be extracted with ui::NSViewIds::GetNSView

[deepak1556]

Current implementation looks good, naming could beGetNativeWindowHandlePointer => GetHandle ?

[MarshallOfSound]

@deepak1556 Initially had it as GetHandle but that conflicted with the concept of a mate::Handle. Added the TODO

[deepak1556]

Initially had it as GetHandle but that conflicted with the concept of a mate::Handle

If you changed TopLevelWindow::GetNativeWindowHandle , I can see the conflict but I don't see how it conflicts when changing NativeWindow::GetNativeWindowHandlePointer to NativeWindow::GetHandle.

Also can you fix the lint failures ? Thanks!

[MarshallOfSound]

@deepak1556 Linting is fixed, let's get this one through 😄

[deepak1556]

The implementation will be changed again in C71, so I am good with current naming convention.

[release-clerk]

Release Notes Persisted

Fixed issue where getNativeWindowHandle() would return an empty buffer on macOS

[trop]

I was unable to backport this PR to "3-0-x" cleanly;
you will need to perform this backport manually.

[trop]

I have automatically backported this PR to "4-0-x", please check out #15644

[tommoor]

Any chance of this being backported to 3.X? 🙏