Hi,
I haven’t completely debug this issue and will add more context, but maybe somebody already has a clue.
We have panel widgets that take data input (looking like a data grid).
In Lab 3.6.7, all is fine.
In 4.1.5, everytime we type some keys in one of the grid cell, it actually executes the equivalent shortcut it seems instead of typing.
So pressing 1 for instance, it converts the parent cell to markdown, kills the VBox cell with the panel, and convert the first line of the parent cell to a markdown header level 1. (like the shortcut would do).
I can’t find where this behavior is coming from now.
The only thing that changed in our image is the version of jupyterlab.
I gonna test in 4.0.x once our image is built.
Anybody knows if it’s a matter of configuring something or creating the VBox differently etc… ?
Thanks
adding more context in jupyterlan 4.1 still.
The behavior is similar to when you’re not in a cell and use keyboard shortcuts.
so
- M converts the cell to markdown
- 1 makes the line a header
- a adds a cell on top
It seems the UI is losing the fact that it’s inside a cell when we are editing the values in the panel.
Do panels/widgets need to be created differently now?
Got more details on our own code creating the widget.
It’s a custom widget that we developed to replace qgrid when it was not compatible anymore with lab.
our panel widget is a bit hackie and added to the output and not a cell.
something like this.
self.table_container = widgets.VBox([self.output])
We gonna try to fix this in our code.
note that the bug doesn’t exist in Jupyter Lab 4.0.13
Something specific that changed in 4.1.x?
Yes. To enable proper keyboard navigation (and fix keyboard traps for users with accessibility needs) changes were made to the kyeboard interaction model in 4.1. These are documented in this section of Extension Migration Guide which I recommend as the first place to consult if something is not working in your extension after upgrading (or when testing pre-releases).
Biefly, since Fix tab trap notebook cells by gabalafou · Pull Request #14115 · jupyterlab/jupyterlab · GitHub the keydown event is no longer caught in the capture phase but in the bubling phase, and the focus in the command mode no longer reverts back to notebook container node (which beside loosing tab index position was also causing random scrolling for some users).
This means that to in order for shortcuts to be active in command mode, we need to specifically exclude the input nodes. This was initially achieved with :focus:not(:read-write) selector but it proved problematic in Panel widgets which used shadow DOM (Typing into into fields that are wrapped with shadow DOM is intercepted by commands · Issue #15757 · jupyterlab/jupyterlab · GitHub), thus a new .jp-mod-readWrite class was added in Fix typing in editable elements inside of open shadow DOM by krassowski · Pull Request #15774 · jupyterlab/jupyterlab · GitHub which peeks into the shadow DOM too.
This is now all documented in Keyboard interaction model section of the JupyterLab notebook docs. It appears that your widget is not detected by the negative selector, possibly because it does not use a native input element, or is not marked as content editable (etc).
We have panel widgets that take data input (looking like a data grid)
How do you implement these widgets? If this is with custom key even handlers, adding a lm-suppress-shortcuts class to the widget container (see the Keyboard interaction model link above) may be a simple solution for you.