Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#16,307 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
説明が足りない
活発さ
静か
技術スタック
react-native
領域
desktop, frontend

調査の方向性

エントリーポイント DesktopPopupSiteBridge から開始し、RN 0.83.2 の新アーキテクチャの例を再現して、透明なモーダルのホスト制約と閉じるボタンの動作を確認します。完了条件は、モーダルのホスティング設計について合意され、{0,0} の測定不具合、透明なオーバーレイ、ネイティブウィンドウのクローズ動作に対する解決策が確認されていることです。

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
C++
スター
17.4k
フォーク
1.2k
平均マージ
2日 17時間
マージ済み PR（30日）
13

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

microsoft/react-native-windows のほかの issue

microsoft/react-native-windows の issue をすべて見る

似ている issue

C++ の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。