[filesystem] File dialog seems to use wrong folder when opened

[federicobozzini]

Description

When a file dialog is opened, it's possible to pass a folder parameter. What I would personally expect would be to see the file dialog getting opened in that folder, what instead happens is that the parent of the folder parameter is used.

This is not the behaviour I would expect and makes it impossible to open a folder that has no subfolders.

Is there a reason behind this?

[akosyakov]

I think too that the dialog should open a given folder, not its parent. I think it is because of historical reasons. It was implemented for Open menu item there opening a parent is convenient, but then we should apply this logic only to Open client.

[vince-fugnitto]

@federicobozzini apparently with our implementation we always go one level higher when opening the file dialog as seen here:

https://github.com/theia-ide/theia/blob/36eba77252634a6227ec5e98eaf3e08f67e08dd8/packages/filesystem/src/browser/file-dialog/file-dialog-service.ts#L77

This means that wether we pass a file or directory URI when calling the file dialog, we open with respect to the parent.

[federicobozzini]

Fixing this would require breaking backward compatibility, are you OK with that?

[vince-fugnitto]

Fixing this would require breaking backward compatibility, are you OK with that?

Maybe we don't necessary need to break the compatibility. Perhaps we can introduce a new optional parameter OpenDialogOptions? which can describe open options when calling the open dialog.

One such option can be where to open the dialog from (ex: folder, parent of folder, workspace root), and would default to our current implementation so that clients would not be broken by this change.

[federicobozzini]

@vince-fugnitto I think it would be quite unusual to have a folder parameter and at the same time an option to use a different folder like the workspace root, but ithat's certainly an option.

[vince-fugnitto]

@federicobozzini I agree, I'm just worried about breaking clients who use the open-dialog-service and notice different results. I'm fine however on making it right, so if breaking is the way to go I'm all for it! 😄

I thought that with OpenDialogOptions? we can essentially support many more possibilities in the future.

@akosyakov what do you think? Would it be fine to break the compatibility like @federicobozzini suggested?

[akosyakov]

I'm fine with breaking. But here i again come to this issue: #4797 We should test and align it with VS Code. I wish someone already creates such extension.