Rework modal to be implemented entirely using public APIs

[acoates-ms]

Description

The current implementation of Modal uses internal APIs which means it did not verify that it was possible to write such components using only public APIs. This PR reworks modal to use the public APIs.

• Start generating codegen'd files for native components in RNW
• Add methods to IReactCompositionViewComponentBuilder to allow custom RootComponentView's
• Instead of implementing Modal by inheriting from the internal RootComponentView class, use the new builder, and the codegen'd types for modal.
• Fixed some issues around focus, where focus would attempt to cross root views
• Switched from using legacy win32 APIs to create the modal window to using the newer WinAppSDK AppWindow APIs.

Microsoft Reviewers: Open in CodeFlow

[PPatBoyd]

comment says the hitTest pt is taken in parent coordinates and we're incorporating the origin in the subrootview (separate window) for it hit test... for the other lines I was thinking "should this origin be incorporated inside hitTest instead of called before it, if it's the RootComponentView()'s layoutMetrics?" ... then saw the if(capturedPointers) { ... } that's more curious. When do we have m_capturedPointers vs not?

Is the underlying type of facebook::react::Point a float? Considering the implications of different DPI on different displays which can do curious things in some contexts

[PPatBoyd]

The overall change looks like formatting only, though I'm curious about the resizing logic relative to positioning logic.

Is the Modal position a controlled property, or pos+size not user-modifiable? I'm a little intrigued at the coordinate system / units for layoutMetrics.Frame being parent window client coordinates / Integer DIPs and our capacity for roundoff -- what scale factor is PointScaleFactor here?

On ~242 we create the AppWindow with the parentHwnd and then appear to clarify the new m_window is a top-level window. It looks reasonable for say a "modal is always centered over its parent" experience but do we have the winrt equivalent of InheritWindowMonitor to avoid separate DPI changes?

I'm a hair concerned about DPI wobbles if crossing a DPI boundary re-invokes layout before/after WM_DPICHANGED and its suggested rect for avoiding DPI wobbles gets processed

[acoates-ms]

The modal as it is right now is sized by its content only, never user modified or user modifiable. So I'm assuming that it will always have the same DPI as its parent? If InheritWindowMonitor is the API to ensure that, we can call it on this window until we get a more complete layout story.

Reworking the shadownode layout to allow more independent layout in the modal, from its parent is currently outside the scope of this change. But something we should think about.

I think of modal as something for quick MessageBox like dialogs. If you wanted something more long lived you are probably better off having a separate API in the JS that launches a window more like how logbox does it. Like a launchDialog('MyComponent', {initialProps}) API, rather than a component that you just render inline.

[PPatBoyd]

InheritWindowMonitor is the API to use here yeah, making the modal's top-level window DPI information be relative to a different top-level window (its owner window; technically not a parent window)

[PPatBoyd]

+1 I think about Modal the same way.

Even better IMO if it's backed by an in-tree UI component and doesn't require a separate top-level window, but it would make sense if there are competing priorities regarding the level of modality supported or allowing the modal to be bigger than its parent surface. An in-tree UI component would probably struggle to offer Code Modality in a brownfield app.

[TatianaKapos]

LGTM!

Just noticed two things that can be resolved in a later PR:

1. Modal has extra white space with the width/height in rntester (this may just need a JavaScript change in rntester)
2. With the UseExperimentalWinUI3 flag, you can only open/close the Modal once. After that any Modal won't open again.