Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#16,307 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Lỗi
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Ít trao đổi
Công nghệ
react-native
Lĩnh vực
desktop, frontend

Hướng nghiên cứu

Bắt đầu từ điểm vào DesktopPopupSiteBridge và tái hiện ví dụ về kiến trúc mới của RN 0.83.2, kiểm tra các ràng buộc của host đối với modal trong suốt và hành vi của nút đóng. Công việc được hoàn tất khi có thiết kế hosting modal đã được thống nhất và có cách giải quyết được xác nhận cho lỗi đo {0,0}, các lớp phủ trong suốt và hành vi đóng cửa sổ native.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Needs: Triage :mag:
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.

Ngôn ngữ chính
C++
Star
17.4k
Fork
1.2k
Merge trung bình
2 ngày 17 giờ
Pull request đã merge (30 ngày)
13

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của microsoft/react-native-windows

Tất cả issue của microsoft/react-native-windows

Issue tương tự

Thêm issue về C++

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.