Native Modal on new architecture opens a separate top-level OS window (DesktopPopupSiteBridge) — transparent flex:1 content measures 0x0, full-screen overlays impossible

Problem Description

On the new architecture, native <Modal> is hosted via DesktopPopupSiteBridge as a separate top-level OS window rather than a layer inside the app window. Three concrete consequences we hit in production:

1. transparent + flex: 1 content measures {width: 0, height: 0}. The modal's child tree receives no parent constraints, so the standard RN full-screen-overlay pattern (flex: 1 or StyleSheet.absoluteFill inside a transparent Modal) renders nothing at all. This part looks like a concrete layout-constraint defect worth fixing independently of any design decision.
2. The spawned window has its own OS title bar, and its X (close) button only emits onRequestClose. That matches RN's contract on paper, but with real OS window chrome the user expectation is much stronger — if JS doesn't wire onRequestClose, the user faces a dead close button on what looks like a normal window.
3. Overlays anchored to app content are impossible: dim scrims, bottom sheets, popovers — anything that composites over the app window — cannot be expressed with native Modal, because the modal lives in a different top-level window.

Confidence framing: architectural diagnosis, reproduced in production; there is no single-line fix to propose. We're filing this to request a design discussion rather than a patch:

• Is a separate top-level OS window the intended long-term host for <Modal> on new arch?
• Could transparent modals be hosted as an in-app-window composition layer (overlay island / popup within the same AppWindow) while windowed behavior remains for the opaque case? Related work items suggest the pieces are being tracked separately (#13160 transparent, #13158 onRequestClose, #15169 title-bar control, #14805 sizing, #14604 focus on DesktopPopupSiteBridge) — but the umbrella question of what Modal is on Windows seems undecided, and it determines the answer to all of them.
• At minimum: should unconstrained (flex: 1) content in the popup window measure the host window's client area instead of {0,0}?

Happy to move this to a Discussion if that's the preferred venue; filing as an issue because the {0,0} measurement is a concrete, reproducible defect.

Steps To Reproduce

1. New-arch RNW 0.83.2 app.
2. Render:

   <Modal transparent visible onRequestClose={close}>
     <View style={{ flex: 1, backgroundColor: 'rgba(0,0,0,0.5)' }}
           onLayout={e => console.log(e.nativeEvent.layout)}>
       <View style={{ margin: 40, backgroundColor: 'white', padding: 20 }} />
     </View>
   </Modal>
   

3. Observe: a separate top-level OS window appears (own taskbar presence/title bar); the content area is empty; onLayout reports {width: 0, height: 0}.
4. Clicking the window's X does nothing unless onRequestClose closes the modal from JS.

Expected Results

Parity with iOS/Android: modal content fills the app window's bounds; transparent modals composite over existing app content; flex: 1 content receives the full available constraints.

CLI version

18.0.0

Environment

System:
  OS: Windows 11 10.0.26200 (ARM64 device; app builds and runs ARM64)
  CPU: (6) x64 Apple Silicon (Windows-on-ARM)
  Memory: 6.49 GB / 15.99 GB
Binaries:
  Node: 22.15.0
  Yarn: 4.5.1
  npm: 10.9.2
SDKs:
  Windows SDK versions: 10.0.19041.0, 10.0.22621.0, 10.0.26100.0
IDEs:
  Visual Studio: 18.6.11822.322 (Community 2026), 17.14.37314.3 (Community 2022)
npmPackages (yarn 4 workspaces — `cli info` reports Not Found in-workspace):
  react-native: 0.83.2
  react-native-windows: 0.83.2 (New Architecture / Fabric composition)
  Microsoft.WindowsAppSDK: 1.8

Community Modules

Not relevant — core <Modal> only.

Target React Native Architecture

New Architecture (WinAppSDK) Only

Target Platform Version

10.0.22621

Visual Studio Version

Visual Studio 2026

Build Configuration

Debug

Snack, code example, screenshot, or link to a repository

Code above. Our production workaround: we avoid native <Modal> for full-screen/transparent overlays entirely and render an in-tree absolute-fill overlay at the app root instead.

Context: found during a Windows hardening pass of a production RNW app (Facilitron FIT — RNW 0.83.2 new-arch, Windows 11 ARM64, WinAppSDK 1.8, 250% display scale). Sibling PRs from the same investigation: #16302, #16303, #16304.

Start at the DesktopPopupSiteBridge entry point and reproduce the RN 0.83.2 new-architecture example, checking the transparent modal's host constraints and close-button behavior. Done requires an agreed modal-hosting design and a confirmed resolution for the {0,0} measurement defect, transparent overlays, and native window close behavior.