Fix keyboard shortcut regressions in new Notebook interface

[jph00]

• I checked to make sure that this issue has not already been filed
• I'm reporting the issue to the correct repository

Problem

@fperez committed that in moving over to a lab-based approach for the new notebook that there wouldn't be a regression in keyboard accessibility, and, more generally, the very strong developer experience in notebook classic. However, after upgrading, I'm already seeing key pieces missing. Therefore I'm opening this issue to attempt to track issues as I see them.

Keyboard shortcuts

• Some of the shortcuts from the Collapsible Headings extension have been added - thank you! However, the ability to hold shift whilst pressing right-arrow has been lost -- this ought to select from the current cell to the end of the section
• ctrl-shift-q is shown in the menu as halting and closing the current notebook, which worked in classic, but it doesn't actually do anything for me (latest MacOS / Chrome)
• o no longer toggles showing/hiding the output of a cell, and I don't see any way to add this
• I can't see a way to add a keyboard shortcut for "run all above current cell" (or ditto for below cell)
• In general, there does not seem to be a way, at least in the GUI, to add keyboard shortcuts to all menu items.

Proposal

Ideally, everything that can be achieved with the mouse would be surfaced as an element that could be tied to a keyboard shortcut via the GUI.

[jph00]

I'd also like to make a request. @fperez in #6210 said:

• Notebook 7 would be released only after ensuring that it really meets the needs of current users as stated above. Critically, this means putting in the necessary work to port/adapt critical extensions like nbgrader, RISE and TOC to work on this future nb7 from Day 1.
• Notebook 6 would remain in minimal maintenance mode at least for a while. Details TBD.

I hope that nb 6 will remain in maintenance mode until enthusiastic nb 6 users have agreed that nb 7 has reached the high bar that v6 achieved! :D

[RRosio]

Linking #6596 touching similar concerns

[jph00]

Thanks for pointing out that existing issue @RRosio.

I'll continue adding regressions here as I find them -- hope that's OK!

Some others that are causing me some trouble:

• A number of lab shortcuts on Mac OS override existing browser shortcuts, at least in Chrome. In particular, cmd-f no longer brings up the browser Find functionality, but instead brings up Lab's. However the Lab functionality does not search in cell outputs, so is not a substitute
• The undo buffer is no longer per-cell, so hitting cmd-z now (surprisingly, to me) changes cells other than the current one
• When switching Windows to focus on Jupyter, the keyboard controls are not on the cells, but on the window itself. Therefore none of the jupyter shortcuts work, and arrow keys scroll the window instead of selecting cells.

[jph00]

An issue with the collapsible headings keyboard shortcut -- pressing 'left' correctly goes up to the parent header; however pressing it again should go to the grandparent header; it doesn't, instead going to the previous header of the same level.

[jph00]

An issue with copy/paste - it is no longer possible to copy and paste cells between notebooks, without using the lab interface. In notebook, it used to work by copying between separate browser tabs or windows.

[fperez]

Thanks for filing these @jph00! I know folks have tried hard to catch these regressions, but things inevitably slip through. Hopefully we can quickly get the UX to be back where it was for Notebook users without any loss of functionality or workflow.

[jph00]

Thanks for filing these @jph00! I know folks have tried hard to catch these regressions, but things inevitably slip through. Hopefully we can quickly get the UX to be back where it was for Notebook users without any loss of functionality or workflow.

Absolutely - I'm definitely not complaining here! Just trying to provide some helpful feedback that hopefully will be useful in getting to where we all want to be. :D

[jph00]

• The option to duplicate the current notebook doesn't exist any more. I'm guessing "Save as" is the replacement. However, after using this, whilst the newly named notebook pops up in a new tab correctly, the old tab no longer works -- the notebook disappears and the error "kernel unknown" appears. The desired behavior is to have both the new and old notebooks running in separate kernels in separate windows/tabs.

[fperez]

Absolutely - I'm definitely not complaining here! Just trying to provide some helpful feedback that hopefully will be useful in getting to where we all want to be. :D

By all means, keep going - this kind of power-user detailed feedback is invaluable, so keep'em coming, and thanks!

[krassowski]

The option to duplicate the current notebook doesn't exist any more.

In JupyterLab there is "Duplicate Notebook" option which was recently exposed in command palette and in the tab context menu jupyterlab/jupyterlab#12870. It appears to be an unintentional omission that it was left out in Notebook, it would be a good first issue to restore it by adding docmanager:duplicate to menus and command palette where needed (which might be as simple as just changing a few JSON files, see jupyterlab/jupyterlab#12870)

There is also a button in the tree view:

[krassowski]

A number of lab shortcuts on Mac OS override existing browser shortcuts, at least in Chrome. In particular, cmd-f no longer brings up the browser Find functionality, but instead brings up Lab's. However the Lab functionality does not search in cell outputs, so is not a substitute

This is incorrect:

I would argue we should make it on by default; it was disabled during a work on performance, and no one said a word since - please do provide feedback, it helps to change things :)

[JasonWeill]

OK, reopened this issue; sorry about the confusion.

Regarding Jupyter taking over CTRL+F/CMD+F: with the new virtual rendering option (currently opt-in), it is possible that your browser's built-in search functionality would not find a search string that exists in your notebook, whereas Jupyter's search function would. It is possible to remap the search command's keyboard shortcut in settings. I'm also open to having an enhancement to, for example, provide a more accessible option to disable this shortcut or to display the browser's built-in search functionality of CTRL+F/CMD+F is pressed twice.

[jph00]

Thanks Jason. As a general UI principal, it's extremely unusual for a web page to override browser behaviour, and is generally discouraged. Can I suggest that the Jupyter team consider this policy too?

There are two quite different behaviors here. One is not better than the other - they are different. Jupyter is running on top of the browser, not the other way around.

[JasonWeill]

@jph00 It's not entirely true that JupyterLab is meant to run only on top of the browser; for example, JupyterLab Desktop is meant to function as a freestanding desktop app, albeit one that happens to use a web view for nearly all its UI. Slack, Visual Studio Code, Spotify, and many other popular apps are built this way nowadays, overriding built-in browser shortcuts in the interest of working more like a "real" app would.

[jph00]

Jason that's pretty disingenuous and patronising tbh. I'll leave this conversation now.

…

Message ID: ***@***.***>

[janxkoci]

@JasonWeill I've reported two issues, but only one was reported separately and resolved. The other issue about access to help system is still unresolved, to my knowledge...

PS: most keyboard shortcuts in old notebook didn't collide with browser shortcuts (except command palette ctrl+shift+p in Firefox) - why is it a problem to keep that?

[krassowski]

As a general UI principal, it's extremely unusual for a web page to override browser behaviour, and is generally discouraged.

I would not call it extremely unusual, certainly not among web pages which provide document/code editing capability. Here are a few examples of web pages which are overriding the Ctrl + F binding to provide a custom search function:

• Google Docs https://docs.google.com/document/create
• Visual Studio Code for the Web https://vscode.dev/
• MS Word (Office 365)
• Overleaf
• CodePen https://codepen.io/pen/
• Replit https://replit.com
• GitHub e.g. https://github.com/jupyterlab/jupyterlab/edit/main/.bumpversion.cfg

In fact I was not able to find an example of a major web page editor which does not do that.

Google Docs:

Visual Studio Code for the Web:

MS Word (Office 365):

Overleaf:

CodePen:

Replit:

GitHub:

Can I suggest that the Jupyter team consider this policy too?

Yes, I think this is a good idea! In fact this is my guiding principle when reviewing PRs adding new shortcuts, for example see jupyterlab/jupyterlab#10425 (review) (of note this is time consuming and done in my free time; it would be great to get more help from community with these kind of reviews, for example by having more users engage in beta testing).

This however is not trivial. For example a pull request jupyterlab/jupyterlab#15790 which made the browser default binding for text insertion higher in priority than the JupyterLab shortcuts had to be reverted because of unintended consequences which users rightly complained about, for example:

• Option-w on Safari was now inserting ∑ instead of closing the JupyterLab tab
• Cmd-Shift-c was now opening both the command palette and the Browser Dev Console
• Ctrl-s was now sometimes invoking browser's "Save as HTML" rather than saving the notebook

I think it is reasonable to expect that there are two sets of shortcuts: for when application is used in a browser, and when it is used as a standalone app. This is in fact what Coder (a non-proprietary version VSCode for web) does, see https://coder.com/docs/code-server/latest/FAQ#how-do-i-make-my-keyboard-shortcuts-work.

Yet, I also think that majority of users expect a set of browser shortcuts to be overridden by Jupyter, even when working in a browser., to name a few less controversial shortcuts: Ctrl+S, Ctrl+C, Ctrl+V.

The F1 shortcut to open help is also not working.

Here we have another expectation of a shortcut which would override default browser action.

with the new virtual rendering option (currently opt-in), it is possible that your browser's built-in search functionality would not find a search string that exists in your notebook, whereas Jupyter's search function would

It is opt-out in 7.2.0rc1. I opened a new issue to track a way to make it work with native browser search by using hidden: until-found (jupyterlab/jupyterlab#16328), however this is for now only supported by Chrome/Edge and would require a major refactor.

[krassowski]

@janxkoci:

I've found no way to access the R help system (not even the Jupyterlab interactive help viewer is present), short of the classic help() function. But such calls pollute the notebook and stay in place while I move around the notebook, which is not ideal.

Indeed it looks like the Contextual Help is not included in Notebook v7. Pressing Shift + Tab does open the help tooltip:

but there is no way to dock it on the bottom or on the side. There are some issues tracking feature parity for contextual help:

• Open the help in a bottom panel #6692
• Show documentation tooltips as in jupyter notebook 6.*  #7034

There is no standalone issue about F1 binding; I now added a comment #7034 (comment) which highlights this - does it sound right?

[janxkoci]

@krassowski Actually, the F1 shortcut was opening the help page in the bottom panel (i.e. rather the UI discussed in #6692). I've never seen the tooltips like that, only those that appear when I press regular Tab.

[JasonWeill]

Hey all! Because we've broken out the remaining issues into individual items in this repository or in https://github.com/jupyterlab/jupyterlab/issues/, I'm going to close this issue. If you have additional bugs or enhancements to report, please open new issues so that we can triage them at our weekly triage at 09:00 PDT on Tuesdays. Thanks!