Dashboard dropdown pickers re-render on every animation frame while open
Maintainer thường phản hồi trong vòng 1 ngày
Đánh giá
- Độ khó
- 1/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- react, typescript
- Lĩnh vực
- frontend
Hướng nghiên cứu
The affected pickers are in ui/combobox.tsx, ui/combobox-events.tsx, and ui/combobox-advanced.tsx; the dependency is pinned in apps/start/package.json. Read the reported rc-virtual-list height collection behavior and compare the pinned version with the upstream fix. Done means idle open pickers stop rendering every frame; an open pull request already tracks this work.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Describe the bug
While any searchable dropdown picker in the dashboard is open, its list re-renders on every animation frame, for as long as it stays open. Nothing has to change for this to happen: no hover, no scroll, no data loading. It stops when the popover closes and starts again the next time it opens.
It's invisible in normal use, but it keeps the main thread busy (a React commit plus a forced layout read per frame) the whole time someone is building a report or a filter.
Steps to reproduce
- Open React DevTools → Settings → enable Highlight updates when components render.
- Open any report and click the event picker in the sidebar (or the Criteria / Unit picker in a retention report, or a filter's value picker).
- Keep the mouse still.
The open list keeps flashing. The update counter on List, Filler and the item components climbs by ~60/s on a 60 Hz display (~120/s on a 120 Hz one), indefinitely.
Expected: the list renders when it opens, scrolls or its items change, and is idle otherwise.
Where it shows up
Every picker built on rc-virtual-list with cmdk items:
ui/combobox.tsx(Combobox): report criteria/unit, the funnel breakdown "From step" picker, Yes/No filter values, overview filters, plus pickers in notification rules, the webhook integration, tracking and organization settings, and onboardingui/combobox-events.tsx(ComboboxEvents): event pickers in report series, fixed events, filters, custom events, events stats, project event filtersui/combobox-advanced.tsx(ComboboxAdvanced): filter values, cohort criteria builder, cohort filters, overview filter buttons, project access grants
PropertiesCombobox (the property/breakdown picker) also uses rc-virtual-list, but its items are motion.divs with a stable ref, and it doesn't loop.
Cause
It's two library behaviours feeding each other:
- rc-virtual-list 3.14.5: every time an item's ref is attached,
useHeightscallscollectHeight(), and that always doessetUpdatedMark(c => c + 1)on the next frame, whether or not a height changed (hooks/useHeights.js). - cmdk:
Command.Itemrenders its<div>withref={mergeRefs([ref, forwardedRef])}, which is a new callback ref on every render. React detaches and re-attaches it on every commit. cmdk 1.x does the same withcomposeRefs.
So each list render attaches a new ref, which schedules a height collection, which re-renders the list on the next frame. And so on.
This was fixed upstream in rc-virtual-list 3.17.1 (react-component/virtual-list#299, "fix: trigger only when changed"): the counter only moves when a measured height actually changes. apps/start/package.json still pins 3.14.5, unchanged since the virtual list was added in 01ed4acc.
Measurements
The dashboard's real Combobox / ComboboxAdvanced components, React 19.2.3, cmdk 0.2.1, production build, headless Chrome at 60 Hz. React commits counted with <Profiler> over 5 s with the popover open and idle:
| Picker | rc-virtual-list 3.14.5 | rc-virtual-list 3.19.2 |
|---|---|---|
Combobox (3 items) |
300 commits / 301 frames | 0 |
ComboboxAdvanced (3 items) |
300 / 301 | 0 |
Combobox (1,000 items, searchable) |
301 / 301 | 1 |
Suggested fix
Bump rc-virtual-list to 3.17.1 or later (3.19.2 is the latest; avoid 3.17.0, which has the hang reported in ant-design/ant-design#52400). Its dependencies and the props the dashboard uses are unchanged. I'll open a PR.
Environment
- OpenPanel
main@ 6521604 (also seen on our self-hosted instance) - React 19.2.3, cmdk 0.2.1, rc-virtual-list 3.14.5
- Chrome on macOS
- Ngôn ngữ chính
- TypeScript
- Star
- 7.2k
- Fork
- 531
- Merge trung bình
- 23 giờ 58 phút
- Pull request đã merge (30 ngày)
- 51
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Không có mẫu pull request
- Không 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 Openpanel-dev/openpanel
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 73/100
Openpanel-dev/openpanel#610 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
ClickHouse retry logs print CLICKHOUSE_URL with its passwordCó thể đã có người làm @ppjsw đã nhận 10 ngày trước. Đang mở
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 92/100
Openpanel-dev/openpanel#551 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
login page needs refinementCó thể làm lại được Pull request cho issue này đã bị đóng mà không được merge. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Openpanel-dev/openpanel#495 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 20/100
Openpanel-dev/openpanel#615 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Session-grouped queries treat every sessionless event as one session (wrong results, ClickHouse OOM)Có thể đã có người làm @grootbro đã nhận 7 ngày trước. Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 52/100
Openpanel-dev/openpanel#575 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của Openpanel-dev/openpanel
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
components-web-app/docs#307 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
localstack/localstack-mcp-server#112 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
area:frontend kind:bug priority:p1 ready
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug ready-for-agent
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 73/100
PhyberApex/kuroshiro#1687 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Performance (Web Vitals) collector: LCP/FCP from background tabs are not discarded, inflating p75Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
umami-software/umami#4720 ·
Maintainer thường phản hồi trong vòng 3 ngày