You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Type a search term with a number of results (my case = 7 matches)
Press the up and down arrow keys
Expected:
Up arrow key and down arrow key move exactly 1 search result in the given direction.
Actual:
Up and down arrow keys jump the selection by 2-4 results, with no consistency in the number of items it jumps by.
Trying the navigation a lot, it looks like maybe it's watching the key UP event, key DOWN event, and key REPEAT event, which is incorrect implementation. If I tap an arrow key really really fast, it jumps the focus by only 2 (every once in a great while it's by only 1), but if I tap it at a normal speed for a 120 wpm typist, it jumps by 2-4. Sometimes I can even see it jump before I release the key and then again after I release the key (which suggests that it's improperly watching for both the down and up events instead of just the down event).
Proper handling for key input is always, in every programming language and GUI, to watch for only the DOWN event for keys, and only the UP event for mouse clicks. For keys that are held down it depends on the programming framework used as to whether it handles the initial delay before the key starts repeating or not, and whether it handles implementing the maximum repeat rate or not. It appears the framework used here does not do this for you, so you'll have to implement your own manual timer delay from when the key DOWN even is received until you start paying attention to REPEAT events, and another timer for filtering the maximum rate you can get the REPEAT events. The OS provides these events to the browser at superhuman speeds intentionally and it's expected the program/site interprets them properly.
The text was updated successfully, but these errors were encountered:
To reproduce:
Expected:
Up arrow key and down arrow key move exactly 1 search result in the given direction.
Actual:
Up and down arrow keys jump the selection by 2-4 results, with no consistency in the number of items it jumps by.
Trying the navigation a lot, it looks like maybe it's watching the key UP event, key DOWN event, and key REPEAT event, which is incorrect implementation. If I tap an arrow key really really fast, it jumps the focus by only 2 (every once in a great while it's by only 1), but if I tap it at a normal speed for a 120 wpm typist, it jumps by 2-4. Sometimes I can even see it jump before I release the key and then again after I release the key (which suggests that it's improperly watching for both the down and up events instead of just the down event).
Proper handling for key input is always, in every programming language and GUI, to watch for only the DOWN event for keys, and only the UP event for mouse clicks. For keys that are held down it depends on the programming framework used as to whether it handles the initial delay before the key starts repeating or not, and whether it handles implementing the maximum repeat rate or not. It appears the framework used here does not do this for you, so you'll have to implement your own manual timer delay from when the key DOWN even is received until you start paying attention to REPEAT events, and another timer for filtering the maximum rate you can get the REPEAT events. The OS provides these events to the browser at superhuman speeds intentionally and it's expected the program/site interprets them properly.
The text was updated successfully, but these errors were encountered: