Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

TextInput with no explicit backgroundColor paints the OS system window color (white strip on dark themes) — TxGetSysColor COLOR_WINDOW falls through to tomAutoColor

未关闭
#16,305 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 2 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
48/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
冷清
技术栈
cpp, react-native

调研方向

从 vnext/Microsoft.ReactNative/Fabric/Composition/TextInput/WindowsTextInputComponentView.cpp 中的 ITextHost::TxGetSysColor 开始,然后将 COLOR_WINDOW 和 COLOR_WINDOWTEXT 的处理方式与 DrawText 的背景行为进行比较。确定默认情况下应使用应用主题资源,还是将绘制交给 composition,并在无样式的 TextInput 不再显示操作系统窗口颜色、而显式背景仍能正常工作时,视为该问题已解决。

由索引模型根据 Issue 内容生成。

描述

Needs: Triage :mag:
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
  1. New-architecture RNW 0.83.2 app with dark-styled UI (most visible when the OS itself is in light mode).
  2. Render <TextInput style={{ height: 44, color: 'white' }} /> — note: no backgroundColor.
  3. Observe: the input paints an opaque white (system window color) strip behind the text.
  4. 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.

主要语言
C++
星标
17.4k
派生
1.2k
平均合并
2 天 17 小时
30 天内合并 PR
13

环境准备

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

microsoft/react-native-windows 的其他 Issue

查看 microsoft/react-native-windows 的全部 Issue

相似的 Issue

更多 C++ Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。