[two_dimensional_scrollables] TableView trailing pinned spans are laid out twice
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 84/100
Research direction
Start in lib/src/table_view/table.dart at RenderTableViewport._updateFirstAndLastVisibleCell, where the non-pinned row and column bounds are calculated. Reproduce with a TableView using trailingPinnedColumnCount or trailingPinnedRowCount, then verify that trailing pinned spans are excluded from the regular range and each TableVicinity is built and laid out once per pass.
Written by the indexing model from the issue text.
Description
Description
In TableView, when trailingPinnedColumnCount or trailingPinnedRowCount is greater than 0, the spans designated as trailing pinned are being incorrectly included in the range of "regular" (non-pinned) spans. This results in these cells being built and laid out twice during every layout pass.
Steps to Reproduce
- Create a
TableViewwith a large number of rows/columns. - Set
trailingPinnedColumnCount: 1. - Observe (e.g., via logs in
cellBuilder) that cells in the last column are built twice.
Expected Results
Each TableVicinity should be built and laid out exactly once per layout pass. Trailing pinned spans should be excluded from the "non-pinned" range.
Actual Results
Trailing pinned spans are included in the non-pinned range because the range is capped by the total metrics length rather than the index of the first trailing pinned span.
Root Cause
In RenderTableViewport._updateFirstAndLastVisibleCell (lib/src/table_view/table.dart), the _lastNonPinnedColumn and _lastNonPinnedRow indices are defaulted to the end of the metrics maps (metrics.length - 1) instead of being capped by _lastRegularColumnIndex and _lastRegularRowIndex.
Proposed Fix
Update the capping logic to use the pre-calculated regular span indices (_lastRegularColumnIndex / _lastRegularRowIndex).
- Dominant language
- Dart
- Stars
- 179k
- Forks
- 31.7k
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 413
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from flutter/flutter
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
c: tech-debt package team-ecosystem
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
waiting for response
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
-
waiting for response
Difficulty 1/5 Under an hour Newbie friendliness 88/100
-
material_ui 1.3.0 & cupertino_ui 1.1.0 on Flutter 3.44 Error: Undefined name 'awaitNotRequired'. Openp: cupertino_ui p: material_ui package team-design
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
code quality good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Suwayomi/Suwayomi-Tsumiru#479 ·
-
Build Failure: agora_rtc_engine compiled against android-31 while dependencies require android-34+ Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 92/100
conceptadev/noir#95 ·