`Ctrl-O` prefixed commands not working in `jupyterlab>=4.1.0`

[rpatel]

Description

Vim command shortcuts that start with Ctrl-O (i.e., Cut Cell, Copy Cell, Paste Cell, Insert Cell Below, Insert Cell Above, Select First Cell, Select Last Cell, Center Cell) are not working since jupyterlab 4.1.0.

At the moment, I am requiring versions jupyterlab==4.0.9 and jupyterlab-vim==4.1.0 to keep these bindings working.

Reproduce

1. Fresh install:
   pip install 'jupyterlab>=4.1.0,<5.0.0a0' jupyterlab-vim

2. In new notebook, any selected cell, edit mode, press Ctrl-O, O or Ctrl-O, Ctrl-O, or Ctrl-O, G, etc… the expected jupyter shortcut doesn't happen (i.e., insert cell below/above, select first cell). However, the editor does respond with the vim command mapped to the keys after the Ctrl-Os. For example, Ctrl-O, O inserts a new line and switches to insert mode, as if the ^O prefix was never pressed.

Context

• Python version 3.12.2
  • jupyterlab==4.1.2
  • jupyter_server==2.12.5
  • jupyterlab-vim==4.1.3
• Operating System and its version: CentOS 7
• Browser and its version: Chrome 121.0.6167.139

Let me know if can provide any additional information.

[ianhi]

I can confirm this bug. @krassowski is there any chance this is related to the shortcut changes again? from https://jupyterlab.readthedocs.io/en/latest/extension/extension_migration.html#change-of-notebook-focus-handling-impacting-command-mode-shortcut-selectors

Please note that :not(:read-write) fragment disables shortcuts when text fields (such as cell editor) are focused to avoid intercepting characters typed by the user into the text fields, however if your shortcut does not correspond to any key/typographic character (e.g. most shortcuts with Ctrl modifier) you may prefer to drop this fragment if you want the shortcut to be active in text fields.

we aren't using that tag, but maybe the auto conversion of things somehow got us?

here's the definition of an example broken shortcut:

https://github.com/jupyterlab-contrib/jupyterlab-vim/blob/b0a90a93b54d55df617f462c209c9fbe94d835d4/schema/plugin.json#L73-L77

[krassowski]

we aren't using that tag, but maybe the auto conversion of things somehow got us?

I do not think so. It seems like the events are not properly intercepted so it might be the fallout from the change of the keydown capture mode in jupyterlab 4.1.

[rchavp]

Any update on this?

[firai]

@krassowski Is there anything we can do at the extension level? Or do we need to wait until https://github.com/jupyterlab/jupyterlab/issues/15897 is resolved?