New File dialog doesn't accept Enter for default

[profbbrown]

Bug Description:

This is in reference to new feature #13303 that was added in 1.48, in which the New File menu item now allows a filename to be entered.

After entering the filename, a dialog box is shown to prompt the user to select a folder in which to create the file. The dialog doesn't allow Enter (or Return) to be pressed to accept the default.

Steps to Reproduce:

1. Select File > New File.
2. Enter a filename, press Enter or Return.
3. On the next dialog box, the user's home directory should be highlighted and the Create File button should be also be highlighted indicating that pressing Enter or Return would select it. But nothing happens when that key is pressed.

Additional Information

• Operating System: MacOS Sonoma
• Theia Version: 1.48

[JonasHelming]

@dhuebner FYI

[dhuebner]

@profbbrown
Thanks for reporting! I will check it.

[dhuebner]

@profbbrown
Are you using the official Theia IDE Desktop app? If yes, which folder is shown in the system file dialog? Is it the same folder that is shown when clicking File -> Open... , or CMD + O?

If you are using a browser app, then this is the standard behavior to preselect/focus the file tree and not the "accept" button in the file dialog.
I'm not sure what is the best default here. On the one hand it is unlikely that the user want to create a new file in the user folder, hence will probably first use the navigation tree to navigate to the project (or what ever) folder. On the other hand for the fast file creation in the user folder it would probably be faster to just hit ENTER instead of using TAB key three times and then ENTER.

[profbbrown]

Thanks for the response. I appreciate the thought that went into the choices that were made.

I expected Enter to work as the default because the Create File button was highlighted. In most other apps, a highlighted button will be the one that is "clicked" when Enter is pressed. Perhaps the answer is to not highlight the button so there's no confusion from a UX perspective.

[dhuebner]

@JonasHelming @tsmaeder
I think this UX issue needs a discussion.
So the question is:
How to highlight default dialog Button when an other dialog component (here a tree) is focused?

[tsmaeder]

I think it's important here to distinguish between keyboard focus an the default button of a dialog. The default button is the one that is "highlighted", but the keyboard focus (at least on windows) is indicated by a dotted line.
T.b.h, I think using a "save as" dialog does not make sense with the UI we have: the user has already selected a file name, the only thing left to chose is the folder it's going to be in. So a "select folder" dialog would be the appropriate choice here.
Alternatively, add an option "Save as" to the initial drop-down menu instead of allowing the user to enter a file name, then the dialog would make sense.
As for the "save-as" dialog, I think we should orient ourselves on the native dialogs. On windows, at least, the keyboard focus seems to initially be on the file name field: if you type something, it goes to that field, but pressing "enter" still completes the dialog with the current values. So focus key strokes seem to be handled at the level of the dialog, not any of its components.

[dhuebner]

@tsmaeder
Thanks for your thoughts!

As for the "save-as" dialog, I think we should orient ourselves on the native dialogs. On windows, at least, the keyboard focus seems to initially be on the file name field: if you type something, it goes to that field, but pressing "enter" still completes the dialog with the current values. So focus key strokes seem to be handled at the level of the dialog, not any of its components.

We could "catch" Enter event and redirect it to the dialog by executing whatever default/active button action is. I think it can not be handled in all cases on the dialog level. Imagine to have a dialog with a text area that has keyboard focus and need to handle line breaks input. It could work if the component "consumes" the event and do not propagate it to the parent component.

[dhuebner]

PR is created #14146