Missing keyboard focus when file opened via single click

[AlexTugarev]

Description

When opening a file with with a single click from the File Explorer widget, the opened editor widget doesn't have keyboard focus.

Reproduction Steps

• GIVEN the editor preview is NOT INSTALLED
• open one editor properly (double click)
• then open a file with a single click
• press ctrlcmd+f
• reveal the first editor widget and see that the search widget is shown there

[Anasshahidd21]

I tried to test it by the steps you provided and the focus seems to be to the right tab.
@AlexTugarev can you verify if this issue is still in occurrence?

[AlexTugarev]

@Anasshahidd21 in your screenshot the Untitled.txt tab was clicked, thus the widget received keyboard focus. A single click from Explorer OTOH doesn't do this.

The difference is hard to tell from looking at the tabs though:

But there are more oddities to the preview feature, e.g. editor's status bar contributions ...

[akosyakov]

Editor preview should never receive a focus if opened on a single click. It is the point of preview that you can navigate through files in the explorer and preview another file.

[akosyakov]

Why do we still trying to fix it? What is the issue here? As I said the editor preview should not be focused while navigating through the explorer. It is by design.

[AlexTugarev]

@akosyakov sorry for the confusion with the editor preview. 'should have recorded with a Theia without it.

It's independent of the editor preview. If you just do a single click in the tree, and then try to search in the then opened editor widget, it won't be possible.

[corneliusludmann]

I can confirm this issue and want to bring up another problem with this behavior:

This happens when the editor.enablePreview is false or not installed at all. When you open a file with a single click the editor will be opened but does not get focus (in contrast to editor.enablePreview=true the file name in the tab is not italic and the editor keeps open even when another file is selected).

When open a Python file with one click and then switch to the debug view to debug the current file, as in the screenshot below, it is not the newly opened file that will be debugged but the previously opened one that had the focus the last time (in this case the readme). Since there is not marker that the file never had the focus (as the italic font when editor.enablePreview is enabled), it is quite confusing as a user.

In my opinion, when editor.enablePreview=false a single click should not open the editor at all. And if it does, then there should be no difference to a double click.

[akosyakov]

In my opinion, when editor.enablePreview=false a single click should not open the editor at all. And if it does, then there should be no difference to a double click.

I think it is in the right direction. There is another preference which controls when something should be opened with a focus something like list.open and then double or single. If there is no editor preview installed and this preference is double then nothing should be opened.

[corneliusludmann]

I think it is in the right direction. There is another preference which controls when something should be opened with a focus something like list.open and then double or single. If there is no editor preview installed and this preference is double then nothing should be opened.

Yes, setting workbench.list.openMode to doubleClick actually works. Thanks for the hint.

However, still find the behavior of workbench.list.openMode = singleClick and editor.enablePreview = false (or not installed) odd. It's not really a preview (or even cannot be recognized as such) but leads to potentially unexpected behavior like the debug issue described above. It's something between preview and open.

[akosyakov]

However, still find the behavior of workbench.list.openMode = singleClick and editor.enablePreview = false (or not installed) odd. It's not really a preview (or even cannot be recognized as such) but leads to potentially unexpected behavior like the debug issue described above. It's something between preview and open.

I've just checked VS Code when the editor preview is disabled and it behaves the same, not sure whether we want to do it differently and what would be implications.

[corneliusludmann]

Actually I don't care if the editor gets the focus or not. I have no problem with the way it is in VSCode. For me, the real issue in Theia is that the debugger (or other functions that rely on what the currently opened file is) does not realize that a file was opened when you use a single click. From the users perspective, I see no difference in the editor view between a single or double clicked file and when I start the debugger I expect that the file of the editor in the foreground will be debugged.

Fun thing: In VSCode you can also debug a preview file (when the filename is italic etc.). You don't need to open the file with active focus. For my taste this is too much. However, when you open a file and you don't have a visual feedback that this file is opened in preview mode only, I would expect that this file is used for debugging when I debug the “current” file (it's also a customer feedback, btw). Probably we could change this behavior somehow?

[AlexTugarev]

I've just checked VS Code when the editor preview is disabled and it behaves the same, not sure whether we want to do it differently and what would be implications.

That is not the same behavior. Even with singleClick open mode, one need to click into the opened editor widget, otherwise keybindings are consumed by the editor widget in background.

[akosyakov]

Fun thing: In VSCode you can also debug a preview file (when the filename is italic etc.). You don't need to open the file with active focus. For my taste this is too much. However, when you open a file and you don't have a visual feedback that this file is opened in preview mode only, I would expect that this file is used for debugging when I debug the “current” file (it's also a customer feedback, btw). Probably we could change this behavior somehow?

@AlexTugarev @corneliusludmann We could introduce a new reference something like a last revealed editor? We could then redefine a context to check first last focused editor and if it is missing then fallback to last revealed. I would assume that in case if a navigator is focused then (last) focused editor will be undefined, but last revealed will be updated as one navigates through rows?

Edited: redefining context is quite a big refactoring, maybe we can rather redefine what is a current editor, maybe like in #7170 (comment)

[akosyakov]

Somehow It feels that defining a current widget as last focused is not enough for a specific kind. Similar discussion here: #7260 (comment)

Should it be then always as following: it is either a last focused widget or a last revealed widget. It means that while there is an active widget of some kind then current should point to it, but as soon as there is no it should first point to previous active, but then start following revealed.

cc @elaihau If we agree on it then in #7260 you don't need another reference, but rather we need some concept like WidgetTracker which encapsulates the logic above and then can be applied in the editor manager and terminal service.