Fix logic for changing keybindings in shortcut editor #16214
Conversation
|
Thanks for making a pull request to jupyterlab! |
The data for use by commands were set on level of individual keys rather than on the level of individual keybindings which let to context menu working on a different item than one would expect (based on key number, not keybinding number).
|
Hi Mike, Screen.Recording.2024-04-20.at.21.37.40.mov |
From the recording, it appears that in Safari you end up clicking on the "Default" text because the accept button is moved to under the "Default". It appears that latest Safari switched to a new (and apparently not quite ready) inline layout implementation - is this the Safari version you are using?
Can you open a dedicated issue for magnifying glass? I think replacing the search component with jupyter-ui-toolkit one would solve the issue. Can you also check if this is happening in released versions already (in that issue). |
Yep, I'm using that new version -> Safari 17.4.1.
I'll do that! :) |
|
In Firefox 124.0.2 on macOS, with this code change, I see the expected behavior. In Safari 17.4.1 on macOS, I see the UI component for a new shortcut overlap some other elements. After I click ✔️ , the new shortcut is not saved.
|
This is a separate issue tracked in #16233 |
* Fix keybinding logic * Fix shortcut/keybinding being set at wrong level The data for use by commands were set on level of individual keys rather than on the level of individual keybindings which let to context menu working on a different item than one would expect (based on key number, not keybinding number).
References
Fixes #16211
Code changes
User-facing changes
Repalcing shortcuts in settings work when a mix of default and non-default shortcuts is used, and when multiple keybindings are used.
Backwards-incompatible changes
None