Explore options for races between event-triggered UI-changes & keypresses

[neiljp]

I'm not sure if there is a general phrase for this, but it is a general issue which applies in many UIs: where a user acts so as to perform an action (typically with a keypress in ZT), but the UI itself has just updated, so the user ends up performing an unintended action instead.

For ZT (and likely all frontends), this could apply to any situation where a UI change is triggered by a server event, such as the updating of the list of users. For the user list we curently move to the top of the list (?), and only once per minute, but handling presence changes more fully means they could be triggered more or less regularly, and what feels like more 'randomly'. Generally the message list doesn't suffer this issue, but anything that happens with subscriptions could be problematic in a similar way.

This behavior might be improved by allowing the cursor to follow entries when they are moved around (if possible), but doesn't resolve situations such as combinations such as 'down-enter' quickly from there. Perhaps the solution could be to add some kind of 'pause' or 'clear-keyboard-buffer' (if that's possible) after changing the UI in this way, to avoid this issue.