Can't do repeated closing of tabs using kb

[ellisonbg]

Open a bunch of tabs in the main work area. Click option+W to close a tab. Repeat. It only works the first time. Something about focus is being lost after the first go, causing the shortcut to stop working.

[echarles]

If it can help to find cause..., changing the tab when the shortcut does not work anymore makes it work again.

[mbektas]

I am looking into this issue

[jasongrout]

See phosphorjs/phosphor#396 (comment) for a suggestion about how to fix this.

[mbektas]

@jasongrout I have been debugging this. I couldn't find a case when a tab is closed while keeping focus somewhere else. For example, if you close the tab using command palette (Close Tab item), palette resets and releases focus to newly activated tab. So, I found it safe to just activate new current tab as a solution.

[jasongrout]

#7684 reverts the changes in #7349 because of unintended side effects. Re-opening this as still needing to be solved.

[jasongrout]

From #8575 (comment), here's another writeup of what is going on:

The mechanics here are a bit tricky. The close shortcut is registered to be applicable to any element that is itself or a descendant of an element with the .jp-Activity css class. This makes sure you can only close actual activities. When the keybinding is run:

1. It closes the shell's current widget
2. Browser focus shifts to the body DOM element, which does not have the .jp-Activity class
3. Subsequent Alt W then do not take effect since it is not considered active for the body element (since it doesn't have a .jp-Activity class)

One workaround is to make the Alt W shortcut just work on the body DOM element, like all the other application-level shortcuts defined next to it. Probably a better thing is to specifically activate the tab that is the document current tab.

My guess is that the same issue happens with the file close and cleanup shortcut.

[renxida]

Was going to file an issue, but found this.

I often need to kill tabs en-masse. Would love to have this.

[andrii-i]

Currently looking into this.

Probably a better thing is to specifically activate the tab that is the document current tab.

@jasongrout would it be reasonable to always focus newly chosen current tab (if there is any)?

[fcollonval]

@andrii-i yes I would say so. The change would need to happen there:

jupyterlab/packages/application-extension/src/index.tsx

Line 212 in 40afbd9

widget.close();

[andrii-i]

@fcollonval Thank you. widget.close() message is what would close the tab as far as I understand. I was thinking the change should rather happen in the same place where TabBar chooses next tab to activate after the current tab is closed. Could you please point me to the logic where a new tab is chosen?

[jasongrout]

First, note that subtleties around Mehmet's attempt at fixing this above, and why the change was reverted and this reopened.

As for how the tab bar picks the current tab after a tab is closed, perhaps that happens in Lumino (I haven't traced through the code recently, but I do remember code that does this sort of thing at https://github.com/jupyterlab/lumino/blob/main/packages/widgets/src/tabbar.ts#L1117)

[fcollonval]

The logic to pick the new current widget is indeed in Lumino; in TabBar

https://github.com/jupyterlab/lumino/blob/e7cc1adcbbfe5df85f2467947b047e9febb98166/packages/widgets/src/tabbar.ts#L1117

Maybe triggering a focus on the new active widget in Lumino is the way forward. But as pointed out by Jason, you must check the behaviour when the tab is closed programmatically - like the launcher case.

[andrii-i]

@jasongrout @fcollonval thank you for the pointers. I will keep case of raise condition created when tab is closed programmatically in mind.

My logic was that because a) listening to currentChanged is the only way we can detect tab change on jupyterlab side and b) Lumino fires multiple currentChanged messages in a quick succession any time tab is closed programmatically as in launcher, there's no way to avoid a raise condition on jupyterlab side. And Lumino has access to source of truth, currentIndex parameter in TabBar / correct sequence of calls to set currentIndex(). I've created an issue 528 in jupyterlab/lumino to track this idea and facilitate a discussion around it on lumino side.

If you have thoughts on how to fix this within jupyterlab (or if I'm missing something in my reasoning), please share and I would love to investigate (e.g. if there is another way to know which tab is current on jupyterlab side outside of listening to currentChanged messages).