fix: preserve committed pages in connector range management in combo-box

[DiegoCardoso]

Summary

A lazy combo-box can get stuck on loading=true when the connector receives a programmatic scrollToIndex jump to an unloaded far page — the existing range-management logic wipes already-committed data and the data-fetch flow stalls. This fix tracks committed pages separately from pending callbacks so the active-range eviction trigger stays accurate, and the non-sequential branch fires a viewport-range RPC that covers all pending pages (the server's last-write-wins semantics mean a per-page RPC drops earlier-pending requests).

ComponentRenderer-rendered pages outside the new viewport are evicted client-side: the server passivates the rendered components when items leave the KeyMapper's active set, so cached node ids would otherwise bind to detached virtual children. Plain-data pages stay in cache.

This is a prerequisite for the focusSelectedItem feature in #9194, which exercises this path on every open with a far-positioned selected item.

Notes for reviewers

A summary comment with the deeper context behind the assertion changes in ComboBoxClientSideDataRangeIT, ItemCountUnknownComboBoxIT, and the commitPage / non-sequential-branch fixes is posted as a separate PR comment to keep the diff readable.

[DiegoCardoso]

Reviewer notes — context for the trimmed comments

Update (4e16446352) — took the review proposal and replaced the connector's local pageCallbacks object with a getter that reads comboBox.__dataProviderController.rootCache.pendingRequests directly off the data-provider controller. Algorithm semantics are unchanged: committedPages still tracks delivered pages, the controller's pendingRequests now plays the role the local pageCallbacks did, and ComboBoxClientSideDataRangeIT + ItemCountUnknownComboBoxIT continue to pass (9/9 locally). The notes below have been retouched to refer to pendingRequests rather than pageCallbacks.

The earlier commit (d54a46832d) removes some long inline comments that read more like commit-message material than code documentation. Posting the historical context here so it's preserved without bloating the source files. Each item below corresponds to a block that was shortened or dropped.

comboBoxConnector.js — non-sequential branch

The full rationale for "fire setViewportRange covering all currently-pending pages, not just the new one":

• _scroller.scrollIntoView(N) jumps the virtualizer; visible placeholders fire index-requested → the data-provider-controller turns them into per-page dataProvider({page, ...}, callback) calls in one rAF batch.
• With pageSize=50 and a render buffer that spans more than one page, the call comes in for two adjacent pages back-to-back (e.g. pages 5 and 6 when scrolling to index 300).
• Each call previously fired its own setViewportRange RPC. These overwrite each other on the server (last write wins), so the earlier-pending page never received data and its entry in pendingRequests lingered → combo-box stuck on loading=true.
• The new range covers every entry in pendingRequests so the latest RPC always covers the earlier ones.

comboBoxConnector.js — commitPage deletion of the pending-request entry

Without delete getPendingRequests()[page] after committing, every subsequent fetch for a different page would treat the just-committed entry as a gap in the active range and incorrectly invoke clearPageCallbacks() across all pages. The deletion is what makes the committedPages Set the single source of truth for "delivered" while pendingRequests reflects only in-flight requests.

ComboBoxClientSideDataRangeIT.scrollToEnd_* assertion change

The pre-PR assertion was "1 page loaded after jumping to the end" (only the last page). The PR's committedPages change preserves page 0 (loaded by openPopup) when the connector receives a non-contiguous request — the older code wiped already-committed pages on a jump as a side effect of the range-management bug. Memory still stays bounded by maxLoadedItemsCount, which kicks in only when total active pages exceed the cap.

ItemCountUnknownComboBoxIT — RangeLog assertions dropped

The original tests verified a specific server-side fetch cadence via RangeLog entries. That cadence depended on the connector's pre-fix range-management bug — every non-contiguous request triggered a clearPageCallbacks() that wiped previously-loaded pages, causing the WC to re-fetch them. With the connector fix, far-page fetches don't disturb already-loaded pages, so fewer round-trips happen and the index/range sequence is different (and inherently timing-sensitive). The behavior the tests still verify — item count growth, visible labels, count-mode switching — is what matters for the feature; the cadence assertions are tied to the old bug and not worth re-asserting under the new behavior.

[vursen]

Do we still need this? The page is already removed by DataProviderController when the data is received via callback.

[DiegoCardoso]

Removed.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[DiegoCardoso]

Closing in favor of #9238