ag-grid: ensureIndexVisible(rowNode.rowIndex, 'top'); not working in V30

I’m submitting a … (check one with “x”)

[X] bug report => see 'Providing a Reproducible Scenario'
[] feature request => do not use Github for feature requests, see 'Customers of AG Grid'
[] support request => see 'Requesting Community Support'

Current behavior

I just updated from V28.2.1 to V30 All looked ok and then I noticed that my rows were no longer scrolling back to the top with this.gridApi.ensureIndexVisible(rowNode.rowIndex, ‘top’);

I have paginated scrolling that is triggered when a reset Grid button is clicked, to find the right page, and then scroll to the correct current selected and highlighted row index.

        if (rowNode) {
            rowNode.setDataValue('selected', true)
            var page = Math.floor(rowNode.rowIndex / this.pageSize);
            this.gridApi.ensureIndexVisible(rowNode.rowIndex, 'top');

In V30, I can navigate to another page, scroll down, hit my reset grid button to trigger the above code, and it will gp back to the correct page but it will not scroll the selected highlighted row into view.

Expected behavior

Without the bug the selected highlighted row is scrolled to the top of the page when I reset the grid that triggers the above code. I can page to another page, scroll down, hit “reset grid” to tigger the above code, and the grid will navigate to the correct page (80 rows per page) and then show the selected highlighted row at the top.

            this.gridApi.ensureIndexVisible(rowNode.rowIndex, 'top');

I reverted back to V28.2.1 and the expected behavior is back. In V30 the code shown in current behavior correctly goes back to the right page, but no longer scrolls the selected row into view at the top.

ensureIndexVisible as shown under scrolling

Please tell us about your environment:

Win 11 X64

  • AG Grid version: V30 and V28.2.1
  • Browser:

“Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/604.1.38 (KHTML, like Gecko) Chrome/49.0.2623 Safari/604.1.38 CoherentGT/2.0”

  • Language: [all | TypeScript X.X | ES6/7 | ES5]


About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 18

Most upvoted comments

Kiril gave in the last comment, we have been waiting for a reproducible example/sample project. Not to open up the conversations surrounding that again, but the point remains that we will not be able to effectively look into this until we can reproduce it.

This tells me you didn’t really listen to what I said. You cannot solve bugs with complex user issues with the only method being “give us a reproducable project or we can’t do anything”. Software doesn’t work like that. It’s only under user conditions that certain issues arise.

I’ve recently solved two extremely hard user issues with my addons using AG-grid that both involved elements of remote debugging, giving the users debug builds in order to gain insight into issues within their context. No way could I ask them for a reproducable context, it just wasn’t possible. You need to use other methods to solve issues, and it’s not an option to tell them “sorry, can’t do anything”.

Your approach to demanding reproducable projects is a very limited system for solving hard problems that only show up in production on user systems.

Why doesn’t the logging work? Why isn’t their more extensive debugging insight?

If there was I might be able to resolve it myself. It would also, ultimately, benefit you to have better debug and logging tools in the application so users are better enabled to solving problems they may encounter in production environments.