While upgrading to HoT 14, I noticed that the keyboard event was no longer propagated to the tabMoves function. While going through the sources to find an example to attach to this question, I noticed that this mistake has already been fixed in a recent pull request, and so my question becomes when do you expect to have this code released?
Another change that I noticed is that pressing shift-tab now inverts the returned values. Earlier, the function passed as tabMoves was responsible for handling the case when shift key was pressed. This is a feature we depend on because we have deliberate logic that determines the next cell to be selected in both directions, so simply inverting the number from “forward” direction is not going to work for us.
While I can think of a way to work around this in principle, it feels wrong to add a workaround for a feature that was silently removed / broken by a library change.
Thank you for contacting us. As for the first question. Handsontable 14.3, which will include this fix, should be released in the middle of April. I will make sure to update you once it’s out.
For the second issue. We had to alter many keyboard shortcuts in v. 14.0, as we implemented accessibility standards that required those changes, so if you have a workaround to change it to your requirements we recommend to implement it.
@adrian.szymanski Please explain why we should have to change our implementation of your TabMoves plugin. We are using it as it is documented. If shift+tab is broken in the plugin, shouldn’t the plugin be fixed?
Let me consult it with our development team, and I’ll get back to you once I have more information. Also, please share an example showing your current implementation.
I will show you a trace of how we’re using the plugin. Here is a sample row in our grid:
It might be hard to see, but the 3 cells to the immediate right of the current cell are readonly (they have a very light grey background). So when I press my tab key, here is a console log of what we send to the TabMoves plugin:
Indeed the cell focus moves to the correct cell:
When I press Shift+Tab, I would expect the focus to go back to the original cell. Here is what we send to TabMoves in that case:
As per the plugin documentation, the plugin is supposed to recognize that Shift was down, thereby navigating the user back to the original cell, which it does before we upgrade:
The example uses a constant object instead of a function for tabMoves. I have modified your fiddle to make both of the problems manifest:
The keyboard event is not forwarded to the tabMoves handler so I can’t detect key, and
Since the pattern of readOnly cells is irregular, the logic for determining the next editable cell is not symmetric. This causes the table to correctly navigate between editable cells on , but it is erratic when hitting +
Please note that the example is simplified to contain just enough complexity to demonstrate the issue, our actual logic is more elaborate.
Thank you for detailed explanation. You mentioned that this issue appears since v. 14.0, right? I checked your example with 13.0 and 12.0, and it behaves the same, pressing Shift + TAB doesn’t return the focus to the original in either of those version. Can you please tell me from which version you are upgrading?
I have good news. This issue will be fixed with the next release, 14.3, which should be out next week. For now you can test it with the pre-release build here: https://jsfiddle.net/handsoncode/nbmrdpLg/
