Default file browser creates new files and folders in a custom drive if installed

[jtpio]

Description

When a custom drive is installed, the default file browser might try to create files and directories in the installed drive, instead of the default file browser.

Reproduce

• Install the latest JupyterLab version: pip install jupyterlab==4.0.10
• Install a custom drive, for example jupyterlab-github: pip install jupyterlab-github
• Click on the GitHub drive input area
• Go back to the default file browser, click on the icon to create a new directory

jupyterlab-drive-focus-issue.webm

Expected behavior

After switching drives, it should be possible to create a new directory in the default filebrowser.

Context

• Operating System and version: Linux Ubuntu 23.04
• Browser and version: Firefox 118 & Chromium 120
• JupyterLab version: 4.0.10

This was initially noticed in jupyterlite/jupyterlite#1263 and jupyter/notebook#7210.

Thanks @brichet for reproducing the issue in JupyterLab 4 as well.

[jtpio]

Creating a new folder uses the following command, which check for the currentWidget in the file browser tracker:

jupyterlab/packages/filebrowser-extension/src/index.ts

Lines 1143 to 1147 in 07b9339

	const widget = tracker.currentWidget;
	if (widget) {
	return widget.createNewDirectory();
	}

[jtpio]

Digging a bit more, this is also an issue in JupyterLab 3:

jupyterlab-3-focus-issue.webm

But it's still odd this started to surface by default in Notebook 7, with the recent pre-releases based on JupyterLab 4.1: jupyter/notebook#7210. In Notebook 7 this is an issue only in 7.1.0a0 and higher, not in 7.0.x.

[jtpio]

This is also reproducible with another drive: https://github.com/jupyterlab-contrib/jupyterlab-filesystem-access

jupyterlab-filesystem-access-issue.webm

[krassowski]

This sounds quite similar to #15290, is it the same issue or a distinct one?

[jtpio]

It looks like a different one, because in this case the tracker current widget is not correct after switching between the default file browser and the drive.

[yogeshiitm]

@jtpio, do you have any updates on this? It's causing issues since we have multiple custom drives.

[jtpio]

@yogeshiitm no update so far, not sure someone had a look at it yet.

[brichet]

But it's still odd this started to surface by default in Notebook 7, with the recent pre-releases based on JupyterLab 4.1

It may be related to the change in toolbars in #15021.
The current widget is tracked by the FocusTracker from Lumino.
It seems that clicking a button (in a widget toolbar, such as new directory) is no longer sufficient for the widget to gain focus.
If you first open a document from the filebrowser, than the widget has the focus again and the command is executed.

EDIT: my mistake, as mentioned above it happens also with previous versions of jupyterlab.

[brichet]

It might be worth taking a look at https://developer.mozilla.org/en-US/docs/Web/API/Event/composed, now the toolbar are web components.

[brichet]

Actually the issue seems to start from https://github.com/jupyterlab/jupyterlab/releases/tag/v4.0.0a23, I can't reproduce it with a previous version (maybe #12281, that change the way the toolbars is created in filebrowser).

[jtpio]

Linking to jupyterlab-contrib/jupyterlab-gitlab#15, which states in jupyterlab-contrib/jupyterlab-gitlab#15 (comment):

I have seen this in JupyterLab 3.6 and now also in 4.2.1.

[brichet]

A few more details on this issue, after trying to solve it in two different ways.

The command to create a directory in a filebrowser uses the WidgetTracker (with the namespace 'filebrowser') to retrieve the active filebrowser. This WidgetTracker uses a focus tracker to change the active widget according to its namespace. Clicking on an element of the widget should change the focus to that element, and therefore change the active widget.

But clicking on a toolbar button does not move the focus to the button or to the toolbar. This is intended, probably to handle the state of the Notebook when using the notebook toolbar. Indeed, the function getState() need to know if the notebook widget is focused after the button has been clicked.

In my opinion, we should:

• give the focus to the button (like in Trigger the toolbar button action on click instead of on mousedown #16470), to solve other potential issues with a focus tracker
• handle the state of the notebook differently, at least when the command comes from a click on a button. We can probably assume that by clicking on a button that performs an action on the notebook, the notebook is expected to be focused. One solution might be to add a default argument to the command about how it was triggered (such as "button click", "keyboard button", "command palette") so that it can be handled differently depending on the situation.