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 :)

[krassowski]

The undo buffer is no longer per-cell, so hitting cmd-z now (surprisingly, to me) changes cells other than the current one

Which version of Notebook are you using? It is per-cell for me:

If you got to /lab → Settings → Notebook do you happen to have "Enable undo/redo actions at the notebook document level." enabled? This is disabled by default.

[krassowski]

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.

Sounds reasonable thing to have as a configuration option to change this behaviour. Can you open an issue in JupyterLab for this one? https://github.com/jupyterlab/jupyterlab/issues

[janxkoci]

The F1 shortcut to open help is also not working. In fact, 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.

Also, I did not find any way to create new notebooks with R kernel. The "new" menu only shows generic "notebook", which creates a Python notebook. Edit: now reported as #7151

Notebook version: 7.0.6
IRkernel version: 1.3.2

[jph00]

An issue that happens multiple times per day, but I'm not exactly sure the chain of events that leads to it: the notebook frontend gets confused about what the currently selected cell is, and the order of cells, when I add a new cell to the end (e.g by copy/paste to the end of the notebook, or by hitting shift-enter at the end). I end up with a situation where the final cell is displayed as the penultimate cell, and pressing down causes the selected cell to go to the last cell, and then to the penultimate cell, and vice-versa. I've found I have to refresh the browser to fix this.

[JasonWeill]

@jph00 Thank you for opening this issue! I may open additional issues to separate this one issue into multiple, easily distributed and independently deployable, issues. I built and installed Notebook from source, at the tip of the main branch earlier today, and I'm going through the issues noted above in comments on particular days:

September 12, 2023

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

• The SHIFT+RIGHT shortcut does not select from the current cell to the end of the section. Opened SHIFT+RIGHT shortcut does not select from the current cell to the end of the section #7364.

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)

• On macOS Ventura 13.6.6 (22G630), with Firefox, CTRL+SHIFT+Q appears in the File menu as a shortcut for "Close and Shut Down Notebook", but pressing this shortcut does not appear to do anything. Opened CTRL+SHIFT+Q shortcut for "Close and Shut Down Notebook" does not work #7365.

o no longer toggles showing/hiding the output of a cell, and I don't see any way to add this

• I can also reproduce this. Opened o no longer toggles showing/hiding the output of a cell #7366.

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

Have you tried opening the JupyterLab UI from the Notebook toolbar, then opening the settings editor, then using the JSON mode, then adding a shortcut for the command notebook:run-all-above or notebook:run-all-below? You can find additional info, and a demo video, in the JupyterLab docs: https://jupyterlab.readthedocs.io/en/latest/user/interface.html#keyboard-shortcuts.

September 19, 2023, 12:47 PDT

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

As @krassowski noted, if you click the "Filter" option in the Find popup, you should see an option to search cell outputs:

The undo buffer is no longer per-cell, so hitting cmd-z now (surprisingly, to me) changes cells other than the current one

Already discussed earlier by @krassowski .

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.

I cannot reproduce this on macOS with either Firefox or Chrome.

September 19, 2023, 19:16 PDT

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.

• I can also reproduce this. Opened Left arrow keyboard shortcut does not navigate up the header hierarchy #7367.

September 19, 2023, 19:17 PDT

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.

There is an open enhancement in JupyterLab about this, opened in 2017: jupyterlab/jupyterlab#1644

It refers to #1286 as a workaround in notebook that was merged in 2016, but now that Notebook relies more heavily on the JupyterLab code, we may need to solve Lab issue 1644 above to implement this.

September 19, 2023, 22:23 PDT

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.

• As @krassowski notes, there is a docmanager:duplicate command that is present in Notebook 7, but that does not have a menu option yet. Opened Add a "duplicate notebook" option that keeps the old and new workbooks open #7368.

November 14, 2023

(by @janxkoci)

The F1 shortcut to open help is also not working. …

Reported as #7151, which is now closed.

May 9, 2024

An issue that happens multiple times per day, but I'm not exactly sure the chain of events that leads to it: the notebook frontend gets confused about what the currently selected cell is, and the order of cells, when I add a new cell to the end (e.g by copy/paste to the end of the notebook, or by hitting shift-enter at the end). I end up with a situation where the final cell is displayed as the penultimate cell, and pressing down causes the selected cell to go to the last cell, and then to the penultimate cell, and vice-versa. I've found I have to refresh the browser to fix this.

• I cannot reproduce this bug, but it is possible that it only manifests after extended usage. Opened Second-to-last cell focused when adding or pasting cells at end of notebook #7369.

[jph00]

@JasonWeill many thanks for creating separate issues for these!

[JasonWeill]

@jph00 I appreciate your help in identifying these! I'm going to close this issue in favor of the new spin-off issues. Please feel free to open more issues as you see fit.

[jph00]

As @krassowski noted, if you click the "Filter" option in the Find popup, you should see an option to search cell outputs:

Yes that's true, and I appreciate this being pointed out. However, I still think that, as a rule, Jupyter should not override builtin keyboard shortcuts. They do not have identical behaviour, and there's plenty of other keyboard shortcuts available, so they should be used. For instance, the builtin browser functionality differs in how it handles closed collapsible sections.

[jph00]

@jph00 I appreciate your help in identifying these! I'm going to close this issue in favor of the new spin-off issues. Please feel free to open more issues as you see fit.

Closing this doesn't give us a place to discuss the other issues that haven't got subissues yet.

[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!