fix(grid): restore trailing scroll emission so top rows aren't lost after fast scroll

[Zneeky]

Closes #17287

Description

Fixes a regression where the top rows of igx-grid / igx-tree-grid /
igx-hierarchical-grid could become invisible after a fast momentum/inertia
scroll back to the top. The scrollbar reports scrollTop ≈ 0, but the
virtualized rows stay frozen at an intermediate startIndex (~row 10–15).

The vertical-scroll throttle on scrollNotify was passing no config, so it
used RxJS's default { leading: true, trailing: false }. Restoring the explicit
{ leading: true, trailing: true } config ensures the final settle position of
a scroll is always processed.

Motivation / Context

The throttle originally used
throttleTime(THROTTLE_TIME, animationFrameScheduler, { leading: false, trailing: true }).
When it was changed to a data-size–dependent throttle(durationSelector) (in
"feat(grids): Apply different throttle based on the amount of data in display"),
the config object was dropped and the operator fell back to the RxJS default
{ leading: true, trailing: false }.

Without the trailing edge, the last scroll events of a momentum flick — including
the scrollTop ≈ 0 settle at the top — fall inside a throttle window (up to 60 ms
for large grids) and are discarded. verticalScrollContainer.onScroll never runs
for the final position, so virtualization stays at the last leading startIndex
while the DOM scrollbar settles at the top → the top rows appear missing.
trailing: true restores the guarantee that the final resting scroll position is
always handled. Independent of zone/zoneless change detection.

Type of Change (check all that apply):

• Bug fix
• New functionality
• Breaking change
• Refactoring (no functional changes)
• Documentation
• Demos
• CI/CD
• Tests
• Changelog
• Skills/Agents

Component(s) / Area(s) Affected:

Grid, Tree Grid, Hierarchical Grid (shared IgxGridBaseDirective vertical
scroll handling / virtualization)

How Has This Been Tested?

• Unit tests
• Manual testing
• Automated e2e tests

Manual: Grid performance sample with 1000 rows — repeatedly wheel-scroll up/down
with momentum and confirm the grid always snaps back to row 0 at the top
(scrollbar at top ⇔ first row visible), where it previously froze around row
10–15.

Test Configuration:

• Angular version:
• Browser(s):
• OS:

Checklist:

• All relevant tags have been applied to this PR
• This PR includes unit tests covering all the new code
• This PR includes API docs for newly added methods/properties
• This PR includes feature/README.MD updates for the feature docs
• This PR includes general feature table updates in the root README.MD
• This PR includes CHANGELOG.MD updates for newly added functionality
• This PR contains breaking changes
• This PR includes ng update migrations for the breaking changes
• This PR includes behavioral changes and the feature specification has been updated with them
• Accessibility (ARIA, keyboard navigation, focus management) has been verified

[Copilot]

Pull request overview

Restores the intended RxJS throttle trailing-edge behavior for grid vertical scroll handling in IgxGridBaseDirective, addressing a regression where virtualization could remain at an intermediate startIndex after momentum scrolling back to the top (scrollbar settles at ~0 but top rows remain missing).

Changes:

• Passes an explicit { leading: false, trailing: true } configuration to the vertical scroll throttle(...) operator to ensure the final “settle” scroll position is processed.
• Adds an inline code comment documenting the rationale and the user-visible failure mode being prevented.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

projects/igniteui-angular/grids/grid/src/grid-base.directive.ts:3707

• This bug fix changes scroll/virtualization behavior but is only manually tested. Please add a regression unit test that simulates a burst of scrollNotify events within one throttle window and asserts the trailing (final) event is processed (e.g., verticalScrollHandler is invoked with the last scrollTop near 0 and the rendered start index updates accordingly). This helps prevent future regressions if the throttle logic is changed again.

        this.scrollNotify.pipe(
            filter(() => !this._init),
            throttle(() =>
                this.throttleTime$.pipe(
                    take(1),
                    switchMap(time => timer(time, this.throttleScheduler))
                ),
                // `trailing: true` ensures the final settle position of a fast momentum
                // scroll is processed; otherwise the last scroll events are dropped and the
                // rows stay frozen at an intermediate startIndex while the scrollbar is at top.
                // `leading: true` keeps the immediate response on scroll start.
                { leading: true, trailing: true }
            ),

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (2)

projects/igniteui-angular/grids/grid/src/grid-base.directive.ts:3706

• The PR description states the throttle config should be restored to { leading: false, trailing: true }, but the code sets { leading: true, trailing: true }. Please confirm which behavior is intended and align the implementation and/or PR description accordingly (enabling leading: true changes behavior vs the previously documented config and may increase scroll handler invocations).

                // `trailing: true` ensures the final settle position of a fast momentum
                // scroll is processed; otherwise the last scroll events are dropped and the
                // rows stay frozen at an intermediate startIndex while the scrollbar is at top.
                // `leading: true` keeps the immediate response on scroll start.
                { leading: true, trailing: true }

projects/igniteui-angular/grids/grid/src/grid-base.directive.ts:3701

• This change fixes a subtle virtualization/scroll regression, but there is no unit test coverage exercising the scrollNotify throttling pipeline (no spec references scrollNotify). Please add a focused test that simulates a burst of scroll events within a throttle window and asserts that the final scroll position is processed (e.g., verticalScrollHandler called for the last event / startIndex returns to 0). This will prevent future regressions if throttle logic is refactored again.

        this.scrollNotify.pipe(
            filter(() => !this._init),
            throttle(() =>
                this.throttleTime$.pipe(
                    take(1),
                    switchMap(time => timer(time, this.throttleScheduler))
                ),

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (2)

projects/igniteui-angular/grids/grid/src/grid.component.spec.ts:2189

• Same as above: if the throttle duration reaches the 60ms cap, waiting only 50ms can intermittently assert before the trailing emission is delivered.

                grid.scrollNotify.next({ target: { scrollTop: Math.round(maxScroll / 2) } });
                grid.scrollNotify.next({ target: { scrollTop: 0 } });
                await wait(50);
                await fix.whenStable();

projects/igniteui-angular/grids/grid/src/grid-base.directive.ts:3706

• The PR description states the intent is to restore throttle(..., { leading: false, trailing: true }), but the code sets { leading: true, trailing: true }. This changes runtime behavior (potentially more verticalScrollHandler invocations) beyond restoring the missing trailing edge. Either align the config with the described behavior or update the PR description/rationale to reflect the intentional leading-edge change and its performance impact.

                // `trailing: true` ensures the final settle position of a fast momentum
                // scroll is processed; otherwise the last scroll events are dropped and the
                // rows stay frozen at an intermediate startIndex while the scrollbar is at top.
                // `leading: true` keeps the immediate response on scroll start.
                { leading: true, trailing: true }