Asagohan Asagohan - 2 months ago 96
AngularJS Question

Angular UI Grid set focus to cell on navigate

I have a grid which is editable. Two of the columns are ItemCode and Quantity. When a user enters a Quantity and presses the down key, I would like the next row to set the focus on the ItemCode cell for the next row. I added this event listener and it goes to the cell, but it quickly flashes into edit mode, then out into selected mode. How can I make sure the cell stays in edit mode?

gridApi.cellNav.on.navigate($scope, function (newRowcol, oldRowCol) {

if (oldRowCol != null && == 'quantity' &&
oldRowCol.row != newRowcol.row) {

UPDATE: Here is my columnDefs:

$scope.gridOptions.columnDefs = [
name: 'itemCode',
displayName: 'Part #',
editableCellTemplate: $scope.itemCodeEditableTemplate,
width: 150,
cellTooltip: function (row, col) {
return row.entity.itemCode
name: 'quantity', displayName: 'Qty', type: 'number', width: 60,
cellTooltip: function (row, col) {
return row.entity.quantity


As I commented above, I believe this is a bug in angular-ui-grid. My workaround is as follows...

The problem is using scrollToFocus() to go to another line, but your normal keyboard operation (tab, down arrow etc) would have taken you to a column that has enableCellEdit: true. So one workaround is to have the column AFTER where you are calling scrollToFocus() from be set with enableCellEdit: false.

It's ugly, but I created a "spacer" column after every column that could possibly be tabbed from.

{ name: 'itemCode', displayName: 'part #' },
{ name: 'quantity', displayName: 'qty' },
{ name: '_spacer1', displayName: '', width: '0%', minWidth: 1, maxWidth: 1, enableCellEdit: false },
{ name: 'someOtherColumn', displayName: 'something'},

So, in my case I wanted to catch a tab from "quantity" to "someOtherColumn" and if the value of row.entity.quantity was 0 (for example), then I would call scrollToFocus() to the next line. Because the normal next cell for tabbing had enableCellEdit: false it would work.

Now for your case, I am not sure it helps, because you are working with down arrow presses, which means you are not changing column with the normal keyboard operation. But perhaps it gives you an idea. (In addition, if your users would tab instead of down arrow, then you can use the workaround, or possibly not even need it, depending on which other columns you have.)

I think a better idea might be to re-open my bug (linked in comments above) and say you are also having the problem and see if you can get a straight answer on what the real fix should be! (I'd love to see it.)