Vertical scrollbar never reappears after resizing window from non-scrollable back to scrollable (ScrollBarComponent::updateVisibility latch)
维护者通常 2 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 3/5
- 预计耗时
- 1-2 天
- 新手友好度
- 76/100
调研方向
从 Microsoft.ReactNative/Fabric/Composition/ScrollViewComponentView.cpp 中的 ScrollBarComponent::updateVisibility 开始,然后跟踪 ContentSize、updateLayoutMetrics 和 updateShowsVerticalScrollIndicator。使用最小的 ScrollView 示例重现调整大小序列,并将 indicator prop 状态与计算出的可见性分离;完成标准是内容再次大于 viewport 时,垂直和水平滚动条都能重新出现。
由索引模型根据 Issue 内容生成。
描述
Problem Description
Problem Description
A ScrollView's vertical scrollbar gets permanently latched hidden once the content has fit the viewport, and never comes back even when a later resize makes the content scrollable again.
Sequence:
- Content is larger than the viewport → scrollbar shows (on hover). ✅
- Enlarge the window until the content fits the viewport → scrollbar correctly disappears. ✅
- Shrink the window again so the content is larger than the viewport → scrollbar does not come back. ❌ (mouse-wheel scrolling still works)
Once the bar has been hidden because the content fit the viewport, no later resize shows it again. The only way to recover is to change the showsVerticalScrollIndicator prop.
Root cause
Microsoft.ReactNative/Fabric/Composition/ScrollViewComponentView.cpp, ScrollBarComponent::updateVisibility (line numbers from the 0.82.5 shipped source):
void updateVisibility(bool visible) noexcept {
if ((m_size.Width <= 0.0f && m_size.Height <= 0.0f) ||
(m_contentSize.Width <= 0.0f && m_contentSize.Height <= 0.0f)) {
m_rootVisual.IsVisible(false);
return;
}
if (!visible) { // (A)
m_visible = false;
m_rootVisual.IsVisible(visible);
return; // early-return: content/size are NOT re-evaluated
}
bool newVisibility = false; // (B) recompute only when visible == true
if (m_vertical) {
newVisibility = (m_contentSize.Height > m_size.Height);
} else {
newVisibility = (m_contentSize.Width > m_size.Width);
}
m_visible = newVisibility;
m_rootVisual.IsVisible(m_visible);
}
The size/content-driven callers pass the previously computed state back in as the visible argument:
// ContentSize(...) -> updateVisibility(m_visible);
// updateLayoutMetrics(...) -> updateVisibility(m_visible);
m_visible defaults to true, and updateShowsVerticalScrollIndicator(value) calls updateVisibility(true|false) from the prop. So m_visible conflates two concepts: the prop showsVerticalScrollIndicator and the computed result (content > viewport).
When the window is enlarged so content fits, branch (B) sets m_visible = false. From then on, every layout/content update calls updateVisibility(m_visible == false), which hits branch (A) and early-returns without re-evaluating content > viewport — so shrinking the window back never re-enables the bar.
Proposed fix
Track the prop separately from the computed visibility and always recompute on size/content changes:
bool m_indicatorEnabled{true}; // set from showsVerticalScrollIndicator
bool m_visible{true}; // computed: (content > viewport) && enabled
void updateVisibility() noexcept {
if ((m_size.Width <= 0.0f && m_size.Height <= 0.0f) ||
(m_contentSize.Width <= 0.0f && m_contentSize.Height <= 0.0f)) {
m_rootVisual.IsVisible(false);
return;
}
const bool scrollable = m_vertical
? (m_contentSize.Height > m_size.Height)
: (m_contentSize.Width > m_size.Width);
m_visible = m_indicatorEnabled && scrollable;
m_rootVisual.IsVisible(m_visible);
}
updateShowsVerticalScrollIndicator(value)→m_indicatorEnabled = value; updateVisibility();ContentSize(...)/updateLayoutMetrics(...)→updateVisibility();
The same applies to the horizontal scrollbar.
Workaround (for app authors)
Toggle showsVerticalScrollIndicator for one frame on every viewport size change, which forces updateShowsVerticalScrollIndicator(true) → updateVisibility(true) to recompute:
const [showVScroll, setShowVScroll] = useState(true);
const onLayout = useCallback(() => {
setShowVScroll(false);
requestAnimationFrame(() => setShowVScroll(true));
}, []);
// <ScrollView showsVerticalScrollIndicator={showVScroll} onLayout={onLayout} />
Steps To Reproduce
- Create/run a Composition (Fabric) RNW 0.82 app whose root renders a vertically scrollable
ScrollView:import { ScrollView, Text } from 'react-native'; export default function App() { return ( <ScrollView showsVerticalScrollIndicator> {Array.from({ length: 60 }).map((_, i) => ( <Text key={i} style={{ height: 40 }}>{`row ${i}`}</Text> ))} </ScrollView> ); } - Launch in a small window → vertical scrollbar appears on hover.
- Enlarge / maximize the window until all rows fit → scrollbar disappears (correct).
- Shrink / restore the window so the rows no longer fit → scrollbar stays hidden, even though the view is scrollable (mouse wheel still scrolls).
Expected Results
After step 4, the vertical scrollbar should be available again (on hover) because the content is once more larger than the viewport.
CLI version
20.0.0
Environment
System:
OS: Windows 11
SDKs:
Windows SDK:
AllowDevelopmentWithoutDevLicense: Enabled
Versions:
- 10.0.22621.0
- 10.0.26100.0
IDEs:
Visual Studio:
- 18.7.11903.348 (Visual Studio Community 2026)
npmPackages:
"@react-native-community/cli":
installed: 20.0.0
wanted: 20.0.0
react:
installed: 19.1.1
wanted: 19.1.1
react-native:
installed: 0.82.1
wanted: 0.82.1
react-native-windows:
installed: 0.82.5
wanted: 0.82.5
Community Modules
From dependencies in package.json:
@expo/react-native-action-sheet: ^4.1.1
@fluentui/react-native: ^0.43.1
@react-native/new-app-screen: 0.82.1
@react-navigation/native: ^7.2.2
@react-navigation/stack: ^7.4.2
@reduxjs/toolkit: ^2.3.0
axios: ^1.9.0
i18next: ^24.2.3
react-i18next: ^15.4.1
react-native-popup-menu: ^0.17.0
react-native-safe-area-context: ^5.5.2
react-native-svg: ^15.12.1
react-redux: ^9.2.0
redux-thunk: ^3.1.0
Note: the bug reproduces with a bare ScrollView and does not depend on any of these modules.
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
Minimal repro is the ScrollView snippet under Steps To Reproduce (no community modules required). Repro is a window-resize interaction (enlarge until content fits, then shrink), so it is not reproducible in a Snack — it requires a desktop RNW window.
- 主要语言
- C++
- 星标
- 17.4k
- 派生
- 1.2k
- 平均合并
- 2 天 17 小时
- 30 天内合并 PR
- 13
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
microsoft/react-native-windows 的其他 Issue
-
Needs: Triage :mag:
难度 2/5 1-3 小时 新手友好度 82/100
microsoft/react-native-windows#16340 ·
维护者通常 2 天内回复
-
bug Needs: Triage :mag:
难度 2/5 1-3 小时 新手友好度 68/100
microsoft/react-native-windows#16321 · 1 条评论 ·
维护者通常 2 天内回复
-
Needs: Triage :mag:
难度 5/5 一周以上 新手友好度 30/100
microsoft/react-native-windows#16442 · 1 条评论 ·
维护者通常 2 天内回复
-
Fabric: activating the window doesn't announce the window or the focused control to a screen reader未关闭Needs: Triage :mag:
难度 4/5 3-5 天 新手友好度 48/100
microsoft/react-native-windows#16435 ·
维护者通常 2 天内回复
-
bug Needs: Triage :mag:
难度 4/5 3-5 天 新手友好度 48/100
microsoft/react-native-windows#16410 ·
维护者通常 2 天内回复
查看 microsoft/react-native-windows 的全部 Issue
相似的 Issue
-
needs-triage
难度 2/5 1-3 小时 新手友好度 70/100
flashinfer-ai/flashinfer#6212 ·
维护者通常 1 天内回复
-
bug graphics
难度 2/5 1-3 小时 新手友好度 76/100
FlaxEngine/FlaxEngine#4295 · 2 条评论 ·
维护者通常 2 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 66/100
Algorithmiq/monoprop#390 ·
维护者通常 1 天内回复
-
docs
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
-
8-membered-ring atrop stereo lost in 2026.09.1可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭bug
难度 2/5 半天 新手友好度 86/100
维护者通常 2 天内回复