Analysis/study page keyboard input
Let's add the keyboardMove input to the analysis and study page. Not sure that the normal location directly under the board is best, but I implemented it there for the time being:
I'm really pumped about this. Especially if you're interested in adding voice after! It's been requested several times. Variants may be tricky.
Totally! Hoping to get voice in there right after. And I also have expectations of bug reports with both given the complexity of analysis+study+variants O_O
Okay it seems to be wired up correctly, ~with only one very questionable bit of hackery~ (fixed now). As for placement, now that we have something to look at maybe we can collectively decide where it should go. There are some outstanding styling issues that I didn't want to spend to much time on in case we decided on a different location.
Now the styling issues aren't as egregious, but with 2 or 3 columns in a crazyhouse study chapter with the keyboard move off, there is a little extra margin. Leaving a note for myself more than anything. Lots to keep track of with all of the possible edge cases.
I like it. I did notice these areas where the various keyboard event handlers need to be deconflicted:
- up and down arrow dont navigate the fork control when the keyboard move box has focus
- hitting tab when the keymove box is focused puts you into a never never land where all navigation keystrokes are discarded. enter won't focus again, clicking the board won't either. you must shift tab, click back to the keymove, or click the movelist to get out of it.
- hitting tab or escape on keymove should probably focus movelist so that any keyboard controls that conflict with keymove intercepts can still be issued.
Good catches. I fixed the up and down arrow behavior in 1a4004b.
It turns out that the computer evaluation toggle was the next thing in the tab order, and when it is focused, or any input element for that matter, mousetrap key bindings are not respected. I solved this two ways:
- I changed the tab order in 06b84be such that the keyboard input was after all of the right hand side tools (ceval, move list, controls, etc) in the tab order. Now, the under board is focused after the keyboard input.
- I allowed toggling the computer evaluation via enter in 7f4517e, only when it is focused. Now if that element happens to be focused and enter is pressed, something happens at least. Since it is an input, it will still be swallowing lots of other key presses (like the arrows).
I tried to move the keyboard input such that the next thing in the tab order would be the move list, but the move list is in the middle of renderTools, and the keyboard input is rendered alongside those tools. Basically the hierarchy doesn't easily allow that. Open to changing the tab order around more if desired.
It's looking a bit wrong on /analysis
Also I couldn't get it to appear on a game analysis page?
Should we put it up on lichess.dev or testy and let some power users see how well it integrates with the existing keyboard navigation?
yes, it's on lichess.dev now
Just catching back up, I can look into why it isn't on the analysis page anymore as well as the styling.
How should I log into lichess.dev? Is there a preexisting user I can use or some way to register? Attempting to register doesn't send me an email at the moment.
Turns out there is an error when rendering the keyboard input before the underboard, but it displays fine after it (and in other positions in the vdom children array). Not sure why that error is happening, the message isn't making much sense to me: Uncaught DOMException: Node.insertBefore: Child to insert before is not a child of this node
Okay I think it's in a better state now for testing
Uncaught DOMException: Node.insertBefore: Child to insert before is not a child of this node
This error usually means something changed the dom that snabbdom manages.
Deployed to lichess.dev!
ready to go?
I think so! I'll keep my eyes out for any bug reports.