TextInput with no explicit backgroundColor paints the OS system window color (white strip on dark themes) — TxGetSysColor COLOR_WINDOW falls through to tomAutoColor
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ó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 48/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Ít trao đổi
- Công nghệ
- cpp, react-native
- Lĩnh vực
- desktop-dev, frontend
Hướng nghiên cứu
Bắt đầu trong vnext/Microsoft.ReactNative/Fabric/Composition/TextInput/WindowsTextInputComponentView.cpp tại ITextHost::TxGetSysColor, sau đó so sánh cách xử lý COLOR_WINDOW và COLOR_WINDOWTEXT với hành vi nền của DrawText. Xác định xem mặc định có nên sử dụng tài nguyên của app-theme hay để composition đảm nhiệm việc vẽ, và coi vấn đề đã được giải quyết khi TextInput không có kiểu không còn hiển thị màu cửa sổ của hệ điều hành, trong khi các nền được chỉ định rõ ràng vẫn hoạt động.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Problem Description
A <TextInput> with no explicit backgroundColor paints the OS system window color (white under default OS settings) behind its text. In a dark-themed app, every unstyled TextInput shows a white strip. The background tracks the OS light/dark setting, not the app's theme, and ignores the RN default of a transparent/unpainted background.
Root cause — confirmed in 0.83.2 source. In vnext/Microsoft.ReactNative/Fabric/Composition/TextInput/WindowsTextInputComponentView.cpp, the ITextHost::TxGetSysColor implementation (line ~334 in the 0.83.2 npm package) initializes cr = (COLORREF)tomAutoColor and, in the COLOR_WINDOW case (~348–351), returns the explicit backgroundColor when set but otherwise falls through to tomAutoColor:
COLORREF TxGetSysColor(int nIndex) override {
COLORREF cr = (COLORREF)tomAutoColor;
switch (nIndex) {
...
case COLOR_WINDOW:
if (m_outer->viewProps()->backgroundColor)
return (*m_outer->viewProps()->backgroundColor).AsColorRefNoAlpha();
break; // <-- falls through to tomAutoColor
RichEdit resolves tomAutoColor for COLOR_WINDOW to the real system window color (white unless the OS is in dark mode). Meanwhile the composition DrawText() path clears to transparent and only fills when backgroundColor is "meaningful" — so the RichEdit-painted system color is what leaks through to the screen.
Candidate fix — we're happy to PR this, pending one piece of guidance. In the COLOR_WINDOW case, when no explicit backgroundColor is set, return a theme-derived background instead of falling through to tomAutoColor, so the input tracks the app's light/dark theme. The adjacent COLOR_WINDOWTEXT case already goes through m_outer->theme()->Color(...) for foreground, so the plumbing exists — what we could not confidently determine from outside the codebase is which theme resource key is the intended default TextInput background (or whether the preferred fix is to make RichEdit paint nothing and let the composition layer own the background entirely). We didn't want to guess at an API in a PR; if a maintainer can point at the preferred accessor/approach, we'll submit the fix.
Steps To Reproduce
- New-architecture RNW 0.83.2 app with dark-styled UI (most visible when the OS itself is in light mode).
- Render
<TextInput style={{ height: 44, color: 'white' }} />— note: nobackgroundColor. - Observe: the input paints an opaque white (system window color) strip behind the text.
- Control: set any explicit
backgroundColor(a dark color) — the strip follows the explicit color, confirming the fall-through is the unstyled path only.
Expected Results
An unstyled TextInput should not paint an opaque OS system color. Expected parity with iOS/Android: transparent (container background shows through) — or at minimum a background derived from the app theme rather than the OS-wide system window color.
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 — reproduces with the core TextInput (deep import react-native/Libraries/Components/TextInput/TextInput, no wrapper components).
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
// Dark screen, unstyled input -> white strip
<View style={{ flex: 1, backgroundColor: '#1e1e1e', padding: 24 }}>
<TextInput style={{ height: 44, color: 'white', borderWidth: 1, borderColor: '#555' }} />
</View>
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, daily-driven at 250% display scale). Our production workaround is to force an explicit backgroundColor on every TextInput via the design system. Sibling TextInput/ScrollView fixes 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
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của microsoft/react-native-windows
-
Fabric text is drawn with ClearType onto transparent composition surfaces, fringing thin glyphsĐang mởNeeds: Triage :mag:
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
microsoft/react-native-windows#16340 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
bug Needs: Triage :mag:
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
microsoft/react-native-windows#16321 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Needs: Triage :mag:
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 30/100
microsoft/react-native-windows#16442 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Fabric: activating the window doesn't announce the window or the focused control to a screen readerĐang mởNeeds: Triage :mag:
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
microsoft/react-native-windows#16435 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
bug Needs: Triage :mag:
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
microsoft/react-native-windows#16410 ·
Maintainer thường phản hồi trong vòng 2 ngày
Tất cả issue của microsoft/react-native-windows
Issue tương tự
-
Round video messages start gray and blocky with libx264: encoder is configured for 1,000,000 fpsĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
telegramdesktop/tdesktop#31422 ·
Maintainer thường phản hồi trong vòng 9 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
Maintainer thường phản hồi trong vòng 5 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
zen-browser/desktop#15809 · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
ggml-org/whisper.cpp#4103 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
bitcoin-core/gui-qml#987 ·
Maintainer thường phản hồi trong vòng 3 ngày