After clicking to a location in the browser, only arrow keys on the keyboard respond

[rickmcgeer]

Describe the bug
This behavior is very strange (and I'm sure it doesn't happen on Macs, or you would have seen it). When I'm editing in the code browser, and I navigate to a spot with a mouse click, pressing a letter key has no effect. Pressing the space bar causes the browser to scroll (page forward is my guess). Backspace has no effect. Once I press one of right arrow, up arrow, everything works again until I navigate with the mouse.
The only error messages I see in the console are when I press the space bar:

[Violation] 'requestAnimationFrame' handler took 73ms
__rootModule___commonjs-entry-35de395a.js:40255 [Violation] 'requestAnimationFrame' handler took 63ms
__rootModule___commonjs-entry-35de395a.js:40255 [Violation] 'requestAnimationFrame' handler took 110ms

Two of these messages appear for every space bar press.

Also, -s is being captured by Chrome, so I can't save.

I also tested this in Microsoft Edge (Version 127.0.2651.105 (Official build) (64-bit)) and there is no problem in Edge.

To Reproduce
This has to be a system-specific issue. I'm on Windows 11, running Chrome Version 127.0.6533.120 (Official Build) (64-bit). The project is https://github.com/engageLively/galyleo-dashboard

Screenshots

Setup

• Windows

Version: Please paste the lively.next commit on which the problem occurred here (use the copy button of the Version Checker in the bottom left corner).
9c51c58

[linusha]

Does this happen reliably for you? As in, the issue persists even after reloading lively/closing and reopening the browser?

I ask this as we know this bug, I sometimes am a victim to it myself (Chrome on Linux), but we were never able to pinpoint it down or reliably reproduce it.

[rickmcgeer]

@linusha closing and reopening the browser seems to take care of it. And it doesm't always happen when I first open the browser. Hmm. An initiation mode that is sometimes triggered and sometimes not?

[merryman]

@rickmcgeer Regarding the "errors" you mentioned, these are not errors but browser warnings for render passes that take exceedingly long, often due to a bunch of processing done during the render pass. Nothing related to the issue at hand here.

So I looked into this and I think we have a classical bug vs feature problem here. What @rickmcgeer is encountering is the problem that after clicking on one of the code entities inside a miller column, the miller column keeps the focus which allows the user to navigate the selection via arrow keys (up and down) or (in the case the cursor is within the bounds of the column) allow for filtering of the entries via keystrokes (a feature @linusha implemented).

So in order to be able to edit the code editor after navigating to a code block via clicking on a code entity, you actually need to click into the code editor since it is not yet focused after navigating via click inside the miller column. Also even though a selection is rendered, there is no visible cursor inside of the code editor after navigation, which is why I guess it never occurred to me that I would be able to edit. I intuitively do not expect something to be editable if the cursor is not displayed.

Now judging by the issue filed by @rickmcgeer, it appears this may not be what people expect.
One could make the case that clicking on a code entity should always lead to an auto focus of the code editor, however that would make the filter feature of the columns not work the same for code entity columns as compared to file columns.
Another thing we could experiment with is to do it the "Squeak way" where we automatically focus on the element in the system browser that the mouse cursor is hovered over? That is certainly inconsistent with the way things are handled throughout the system but in this case it may be more what people expect?