Next Release Target: 20th Aug (v26.0.0)

You can workaround this issue by setting the gridOptions rowBuffer property to a larger value to pre-render more rows to allow the row span to render correctly. By default rowBuffer is 20, so if you have row spans with more than 20 rows, that will cause the issue. You can fix this by setting the rowBuffer property to a value equal or bigger than the number of rows in the largest row span you have. For example, so if your biggest row span is 100 rows, set rowBuffer to 100 to resolve this as shown here: https://plnkr.co/edit/syUbfeLUnYFEXhxJ Note that in this example the row span is correctly shown as you scroll down. The rowBuffer property is documented here: https://www.ag-grid.com/documentation/javascript/grid-properties/ Please keep in mind that using a larger value for rowBuffer will increase the memory footprint, as it pre-renders a larger number of rows before they're scrolled into view.

You can implement this using a CSS workaround as shown here: https://plnkr.co/edit/UVo1rPgCqSaZT16k

You can implement this behavior using the approach and samples here: https://blog.ag-grid.com/deleting-selected-rows-and-cell-ranges-via-key-press/

This filter behavior can be added to the default filter with a custom filter option as illustrated here: https://plnkr.co/edit/jaAXviTMWrEAoedd

The performance impact of cycling through all the nodes is minimal. If you're seeing performance issues, please submit a support ticket with an running sample illustrating this and we will investigate and assist.

You can implement this in user code as shown here: https://ag-grid.zendesk.com/hc/en-us/articles/360018518798

In order to auto-size columns which are currently not in view, please turn off column virtualization by setting suppressColumnVirtualisation=true This is covered here: https://www.ag-grid.com/react-grid/column-sizing/#auto-size-columns

Use workaround below (requires suppressing row virtualisation): https://plnkr.co/edit/LKhBiILYlBFCJdRj

Until this is implemented, please call the valueFormatter function for the column when exporting its value in processCellCallback. This way you can apply the same valueFormatter logic when exporting the cell values.

See workaround below using postProcessPopup to render popup inside viewport: https://plnkr.co/edit/CEItOAvM7gU263EU

Workaround - while in Japanese Hiragana input mode, select a cell, press ENTER key to start editing, then you can enter Japanese text

You can implement this by showing a dummy column only in the case no other columns are visible to allow access to the column menu. This approach is implemented here: https://plnkr.co/edit/40OvlMuxC8u6sByU

Please implement this as shown here: https://ag-grid.zendesk.com/hc/en-us/articles/360007567477-Create-Filter-with-AND-OR-Conditons

******* For the time being, we've created a workaround which you can find in the following Plunker which uses a hard-coded refresh: https://next.plnkr.co/edit/peUBAixMVzg3KZfM ******

We did some analysis on this and determined we won't address this issue due to the complexity it introduces vs the benefit. A working solution would require us to detect which other rows need to be rendered in the DOM before we encounter them due when row spanning is enabled. A possible workaround for some users would be to set the rowBuffer to a sufficiently large number

Please implement this functionality in user code following the approach illustrated here: https://blog.ag-grid.com/wrapping-column-header-text/

You can implement row grouping for columns with null/undefined values as follows: https://plnkr.co/edit/rNC5GYdmRLR9Y4LZ

This functionality is currently supported when using SSRM with Full Store. This isn't supported when using Partial store because the rows get reloaded from the server when sorting/filtering. Steps to illustrate for SSRM-full store: 0. Open https://plnkr.co/edit/g9kO1ZQ1sY3CSGFd 1. Select a row 2. Click group column header to sort Actual & Expected: The selected row is maintained

It was never intended for the Column Groups to be included when doing autosize for a column. I have updated the docs to be explicit about this. Given the grid is working as intended, I'm closing this as a bug.

You can implement this when using server-side row model with infinite scrolling using the approach described below. If you have a block size of 200 and want to start loading the next block (with rows 200-400) as soon as the user is scrolling past row index 100, you need to set rowBuffer=100. This way when the user is at row 101, the grid is instantiating row 201, and as that's outside of the data for the current block 0-200, that forces a request for a new block of data (with data for rows 200-400). See this implemented here: Infinite row model - https://plnkr.co/edit/MR8mzfOAQkrGsS5s?preview Server-side row model - https://plnkr.co/edit/gEa4EdlRbVN8cjmo See the messages in the developer console indicating the second block of data is loaded much earlier as the user is scrolling, so the user doesn't see loading indicators unless they scroll really fast. If that's the case, just increase the value of cacheBlockSize to load larger chunks of data at a time to accommodate that.

This can't be fixed simply. It's to do with the hardware accelerated scrolling that iOS does. We have listeners that update the header as the body moves, however iOS is doing hardware acceleration to move the body first, then firing listeners second, so body has scrolled before grid is informed of it, thus grid lags behind.

The Grid can't be used to support this use case. Loading Overlays are intended to be used when the grid is loading data from a remote server. While the grid is processing a pivot operation, the JavaScript thread is locked up performing calculations and it's not possible to update the UI.

this change is on purpose, we won't be fixing to go back to the old way.

workaround: https://next.plnkr.co/edit/ktiodLUdWUjgNIvg if we did 'fix' this, it would be breaking change for other users who depend on the current way it works. what the user is asking for is fair, but how it works is fair also, it's 50/50 as to which one is right. given there is a workaround to change the behavior, this is not needed.

This is expected behaviour, when rangeSelections are enabled, clicking on the same cell multiple times will create a new range for each click. If this behaviour is undesired set the gridOptions property: suppressMultiRangeSelection=true. I tried to reproduce in latest and could not. Am assuming it is fixed.

This is not easy to implement. As there is no cell that was clicked on, the grid doesn't know what the column is. This is also not blocking any business functionality - user just needs to right click the cell.

In order for the cell to be refreshed, the grid needs something, either 'field' or 'valueGetter' set on the column, so it can get the value. That is the only way the grid can then tell that the value has changed and the cell needs updating. This is due to the change detection the grid does. To solve, include a valueGetter that will return a different value when the data is loaded. Demonstrated on this plunker: https://plnkr.co/edit/elOLcKx5Y6EnEwHi

This is the workaround, it autosizes cols first before sizing cols to fit: function sizeColsToFit() { // STEP 1: need to autosize cols first to achieve consistent results var allColumnIds = []; gridOptions.columnApi.getAllColumns().forEach(function(column) { allColumnIds.push(column.colId); }); gridOptions.columnApi.autoSizeColumns(allColumnIds); // STEP 2: then size cols to fit gridOptions.api.sizeColumnsToFit(); } https://plnkr.co/edit/02RGrvx6f0VESIQJqPKz?p=preview Note the reason for this inconsistent behaviour is due to the algorithm uses a ratio of widths and takes the actualWidths into account, but these are successively changing. The workaround ensure that each time we call sizeColumnsToFit() the actualWidths will be the same each time.

Until this is implemented, you can add this functionality using a temporary workaround solution like this: https://plnkr.co/edit/r0JNpRuKLywzhCmV Note: The example above won't work inside Plunker due to its ClipboardAPI security limitations, so follow steps below: 1. Open https://plnkr.co/edit/r0JNpRuKLywzhCmV 2. Open in a separate window using the button just above the live preview pane 3. Click a cell 4. Press CTRL+C 5. Right-click any other cell to open context menu 6. Click the PASTE context menu Actual & Expected: Copied value gets pasted

We have created the following example: https://next.plnkr.co/edit/tRskkv08jyOLmmv9?preview Note that this is pretty much like a custom rewrite of the aligned grids to suit your needs.

There is a workaround in our knowledge base: https://ag-grid.zendesk.com/hc/en-us/articles/360020374692