Issue description:
Currently jsTree uses ‘keydown’ event for node activation.
But this approach has some significant gaps:
1. Keyboard ‘keydown’ event could be triggered multiple times while user presses and holds ‘Enter’ key on the focused node.
It is crucial for the cases where node activation triggers server requests.
For example, for the jsTree demo page https://www.jstree.com/demo/ we have a ‘Database demo’ example:
After we move focus to ‘gf’ node and hold ‘Enter’ key on it for a second we will get a set of similar requests:
Hence, even small user delay will significantly increase server load. And holding a key for a few second would provoke some kind of small DDOS attack.
Talking about accessibility aspect of this situation we could imagine an user with some motor disabilities (E.g. tremor) that causes him to interact with keyboard with a delays – this user might cause a significant server load.
2. Keyboard ‘keydown’ event might be transferred to another target if node activations provoke focus change.
We could imagine the next scenario:
jsTree is used to represents file structure. Activating file node open download confirmation dialog that have ‘Ok’ and ‘Cancel’ buttons.
The user set focus on the file node
The user presses and holds ‘Enter’ key. This action starts triggering set of ‘Keydown’ events
Node triggering opens confirmation dialog and sets focus on ‘Cancel’ button which also activated using ‘keydown’ event.
As holding ‘Enter’ key keeps triggering ‘keydown’ – this event will activate ‘Cancel’ button and close the dialog.
By this way, we are able to perform two separated actions by one logically atomic interaction (From the user side) – pressing ‘Enter’ key and releasing it with some delay. This situation could look bad for the UX.
Potential solution:
To improve the situation, we could start to use ‘keyup’ event for node activation (By handling ‘Enter’ key separately from other keyboard events). Arrow navigation will remain unchanged and will continue to use ‘keydown’ events.
By this way, node activation will be one-time event triggered only once when the user releases the ‘Enter’ key.
If we want to keep old behavior, we could create a new option ‘keyup_nodes_activation’ and set it default value to false.
@vakata what do you think about this potential improvement/fix? If it looks acceptable, I could create PR for this case. If you have some suggestions about how to better handle this situation I would appreciate if you shared them.
Issue description: Currently jsTree uses ‘keydown’ event for node activation. But this approach has some significant gaps: 1. Keyboard ‘keydown’ event could be triggered multiple times while user presses and holds ‘Enter’ key on the focused node. It is crucial for the cases where node activation triggers server requests. For example, for the jsTree demo page https://www.jstree.com/demo/ we have a ‘Database demo’ example:
After we move focus to ‘gf’ node and hold ‘Enter’ key on it for a second we will get a set of similar requests:
Hence, even small user delay will significantly increase server load. And holding a key for a few second would provoke some kind of small DDOS attack. Talking about accessibility aspect of this situation we could imagine an user with some motor disabilities (E.g. tremor) that causes him to interact with keyboard with a delays – this user might cause a significant server load.
2. Keyboard ‘keydown’ event might be transferred to another target if node activations provoke focus change. We could imagine the next scenario: jsTree is used to represents file structure. Activating file node open download confirmation dialog that have ‘Ok’ and ‘Cancel’ buttons.
Potential solution: To improve the situation, we could start to use ‘keyup’ event for node activation (By handling ‘Enter’ key separately from other keyboard events). Arrow navigation will remain unchanged and will continue to use ‘keydown’ events. By this way, node activation will be one-time event triggered only once when the user releases the ‘Enter’ key. If we want to keep old behavior, we could create a new option ‘keyup_nodes_activation’ and set it default value to false.
@vakata what do you think about this potential improvement/fix? If it looks acceptable, I could create PR for this case. If you have some suggestions about how to better handle this situation I would appreciate if you shared them.
Regards, Volodymyr