Igniteui-angular: Keyboard Tab Navigation not working when using conditional cellEditEnter.cancel

[RolandTa]

Description

When using a conditional cellEditEnter.cancel to prevent certain values to be edited based on the current rowData the tab navigation behaves wrong.

When starting editing a cell the user should be able to navigate through all cell in the row with tab. However this will not work when there is a column in between which was cancelled for editing during the cellEditEnter event based on the rowData. After that the cell is selected (but not in editMode which is correct). An additional tab will focus out of the current row to the next best element to focus on - it should navigate to the next editable cell in the same row.

• igniteui-angular version: 10.2.0
• browser: Chrome 86.0.4240.111

Steps to reproduce

Open https://stackblitz.com/edit/github-aejnxt

1. Start Editing the "Chai" cell and tab further down the row -> all cells will be navigated properly
2. Start Editing the "Chang" cell and tab further down the row -> you are losing focus on your current row after the unitOfStock column

Result

The User is unable to navigate through a row with tab when a column editing is cancelled.

Expected result

The system should navigate properly through the row. In addition the keydown event will not fire an event for the tab key when the key is pressed within a cell which is not in editmode (ie unitOfStock in the above case).

[github-actions[bot]]

There has been no recent activity and this issue has been marked inactive.

[Aleksandyr]

Hello @RolandTa, this is the desired behaviour of the grid. Once a cell is not in edit mode tab focuses the other focusable part of the grid. You can try this with any cell that is not in edit mode. If you want to proceed with editing, you have to navigate with the arrow keys to the right or up or down or whatever, then press enter in order to trigger editing again and proceed with the tabulation until the editing ends again.

As you can see from the documentation itself it is written that:
Tab available only if there is a cell in edit mode; moves the focus to the next editable cell in the row;

[RolandTa]

Thanks @Aleksandyr for your explanation. Just to clarify the requested behavior here in addition to the current solution.

From the user point of view he is currently in edit mode - see the above example code https://stackblitz.com/edit/github-aejnxt - the user starts by editing the "Chai" cell and double tabs to cell orderdate in the very same row while still maintaining the edit mode. He is now able to change the orderdate.

However as soon as we start editing the "Chang" cell (start editmode by double click) and double tab to cell orderdate to adjust this value as well we are loosing the edit mode entirely - in addition the grid focuses the next focusable element which in the current situation is not the cell orderdate.

Maybe we are misusing the cellEditEnter.cancel event entirely for our usecase, but what we want to achieve is to disable data editing based on the current rowdata for certain cells (when a certain value is present you are not allowed to edit cell X) - this should however not effect the normal editing workflow of the user by throwing him out of the current edit mode.

[Aleksandyr]

@RolandTa I think I got your scenario, but it is how the grid works. If you want to validate in some way the input value of the grid here is a really simple example of how you can prevent submitting the value of a cell and at the same time stop navigating and tabulating in the grid.

You can achieve it just right before submitting the value via cellEdit event.

Here is the whole lifecycle of the grid's editing events.

[Aleksandyr]

Here is another example of how you can return the old behaviour of the grid and tabulation in the tbody by overriding the default grid keyboard navigation.

As you can see you have references to the prev and next cells of the grid giving you all the information needed for you case scenario.

[RolandTa]

@Aleksandyr Thanks for your samples and further details. However we dont think its a good approach to let the user enter a value even though the system knows the value cannot be edited and then cancel it as soon as the user tries to submit it (as described in your comment#1)

Your second example by overriding the default keyboard navigation does not work properly as well. In our case we dont know which of the following cells are editable (some of them will be cancelled based on the current rowdata). We could however jump to the next cell as soon as the user press tab whenever we identify a situation like the current node is not in editmode. However this seems a bit too hacky and will break as soon as there are more then one cancelled cell next to each other.

From our standpoint this should be a built in behavior from the grid. To our surprise the grid behaves correct when using row editing mode - see https://stackblitz.com/edit/github-aejnxt-hnarxz and use the same two rows as in my description above.
You will see that the cancelled cell remains in focus and an addition tab will set the next cell in editmode (like we would expect). The user will not be interrupted within his workflow.

Is it possible to mirror the behavior to the cell based editing mode?

[Aleksandyr]

@RolandTa I can understand you really well, but those two features are completely different from one another (cell/row edit).
In row edit, there is a transaction that keeps all that editing process in the context of the actual row, so until you press one of the template buttons (enter/cancel) are just press esc the editing is always open.

It is not the same for the cell though. The editing context is different here, it is per cell, so once you step out of the cell editing the whole editing ends.
It is completely logical that behaviour we have so far with the cancellation of the cellEditEnter as you are preventing the cell to enter in edit mode, which closes the whole editing lifecycle.

If you would like to break that behaviour and be always in edit mode no matter whether you are stepping over a column/cell which is not editable or cancelling the events that enter in edit mode when will be your breakpoint of exiting the whole editing lifecycle? Because once you enter in edit mode and start going over the cells, you will stay forever in edit mode.

[zdrawku]

Thank you Alex, for the detailed explanations. All in all, this is the default behavior of Grid's editing capabilities and for anything else a custom solutions should be implemented on application level.

[RolandTa]

@Aleksandyr @zdrawku We will now try to implement a custom behavior to fulfill our requirement. If this will not work we will discuss changing the edit behavior to row based mode. Thanks for your support and further explanations.