[Bug] Virtual scrollbar overlaps the content instead of reserving a gutter
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 55/100
- Type d'issue
- Bug
- Clarté
- Clairement spécifiée
- Activité
- Active
- Stack technique
- react, typescript
- Domaine
- frontend
Piste de recherche
Start in src/ScrollBar.tsx and trace how the scrollbar is rendered alongside the holder and positioned against the list root. Compare the vertical and horizontal cases, including right-to-left positioning, and check existing scrollbar and layout tests. Done means virtual scrollbars no longer overlap the content or last row, with spacing preserved in both directions.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Related antd issues (this was found while working on antd's Listy):
- ant-design/ant-design#59641 — spacing between the content and the virtual scrollbar
- ant-design/ant-design#59633 — the virtual scrollbar thumb colour falling back to
rgba(0, 0, 0, 0.5)
What problem does this feature solve?
In virtual mode the custom scrollbar is absolutely positioned at the right edge of the list root and does not reserve any space, so the content underneath it gets covered.
Concrete case — antd Listy:
- The row breathing room lives on the item itself:
.ant-listy-item { padding: 12px 16px }— that 16px right padding is what separates the row content from the list edge. - The vertical scrollbar is 8px wide and sits at
right: 0of the list root. - Net effect: the scrollbar covers the rightmost 8px of that 16px padding, so the gap between the content and the scrollbar is 8px instead of 16px — and unlike a native overlay scrollbar this one is always visible, so the halved spacing is permanent.
Measured (antd 6.6.7, Chrome 155, macOS 26.7), list width 320px:
| mode | item right padding | content box right edge | scrollbar left edge | content → scrollbar |
|---|---|---|---|---|
virtual |
16px | 336px | 344px | 8px |
| non-virtual | 16px | 336px | 352px | 16px |
Same component, same items, same width — only the spacing differs because of the virtual switch.
Repro: https://codesandbox.io/p/devbox/k3g67m?file=%2Findex.tsx — two <Listy> side by side, the top one with virtual, the bottom one without.
What does the expected behavior look like?
The scrollbar should not sit on top of the content. Either:
- reserve a gutter for it (e.g.
scrollbar-gutter: stable, or add the scrollbar width to the content box), or - behave like a native overlay scrollbar (visible on hover / while scrolling only).
At minimum the distance between the content and the scrollbar should not change when toggling virtual.
Where the code lives
src/ScrollBar.tsx:
const containerStyle = {
position: 'absolute',
visibility: visible ? null : 'hidden',
};
// vertical
Object.assign(containerStyle, {
width: 8,
top: 0,
bottom: 0,
[isLTR ? 'right' : 'left']: 0,
});
The scrollbar is rendered as a sibling of the holder and positioned against the list root, so the content box is never inset by the scrollbar width.
Additional notes
- The horizontal scrollbar has the same problem in the other direction (
height: 8; bottom: 0) — it covers the bottom padding of the last visible row. - The thumb colour falls back to
rgba(0, 0, 0, 0.5)here (var(--rc-virtual-list-scrollbar-bg, rgba(0, 0, 0, 0.5))); consumers currently have to override that variable themselves, e.g. antd does it per component (see ant-design/ant-design#59633). - Consumers also work around the overlap themselves — e.g. antd's
Treeaddspadding-rightto its list to keep the row highlight clear of the capsule scrollbar. Handling it once here would be better for every consumer.
Environment
- @rc-component/virtual-list: 1.5.2
- antd: 6.6.7 (the consumer used for the measurements above)
- Chrome 155.0.8059.85 / macOS 26.7.1
- Langage dominant
- TypeScript
- Étoiles
- 812
- Forks
- 171
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Préparer son environnement
Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de react-component/virtual-list
-
Difficulté 2/5 1-3 heures Accessibilité débutants 58/100
react-component/virtual-list#325 · 1 commentaire ·
-
渲染第一项高度变更,滚动位置不准确Ouverte
Difficulté 4/5 3-5 jours Accessibilité débutants 35/100
react-component/virtual-list#303 ·
-
希望添加横向虚拟滚动Ouverte
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 25/100
react-component/virtual-list#297 ·
-
嵌套滚动内容时,内部滚动效果会直接穿透到外层虚拟列表不生效Ouverte
Difficulté 4/5 3-5 jours Accessibilité débutants 35/100
react-component/virtual-list#292 ·
-
Difficulté 3/5 1-2 jours Accessibilité débutants 42/100
react-component/virtual-list#290 · 1 commentaire ·
Toutes les issues de react-component/virtual-list
Issues similaires
-
enhancement
Difficulté 2/5 1-3 heures Accessibilité débutants 73/100
ajv-validator/ajv#2689 ·
-
[Bug]: IME confirmation Enter can submit the SSH port-forward dialogPeut-être pris @seijikohara l’a pris aujourd’hui. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 88/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
home-assistant/frontend#55323 ·
Les mainteneurs répondent en général sous 1 jour
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficulté 1/5 Moins d'une heure Accessibilité débutants 72/100
lingdojo/kana-dojo#33188 · 1 commentaire · 5 réactions ·
Les mainteneurs répondent en général sous 1 jour
-
self-driving
Difficulté 1/5 1-3 heures Accessibilité débutants 86/100
Les mainteneurs répondent en général sous 1 jour