Add 'Upload Files...' menu entries

[akosyakov]

fix #4088

TODO:

• fix handling of global selection by the navigator: it does not clean it up on disposal
• relocate & group download & upload in the main menu
• relocate & group download & upload in the navigator context menu
• reveal a folder in the navigator after upload
• open a CQ for formidable - it's MIT and does not have 3rd party dependencies, we can wait till the CQ process for prod dependencies is clear
• sign off a commit properly
• uploading to the same folder twice should work

[akosyakov]

@kittaakos i've removed it, seems to be just left overs which were never used

[akosyakov]

@jankeromnes @jgbradley1 Could you try it out?

[akosyakov]

@vzhukovskii There was a bug in the navigator and plugin tree views that the global selection was not cleaned properly when they are disposed. I've introduced TreeWidgetSelection to deal with that in TreeWidget. One can enable it via globalSelection props. Could you please have a look that it does not break menu items for tree view? I will do it as well.

[vzhukovs]

@akosyakov thanks! Will try to check it asap.

[vzhukovs]

Looks like it doesn't break existed logic on plugin side.

[jgbradley1]

Nice. I like it! One minor UI issue. If a user has a directory open (i.e. by clicking on the drop down arrow) in the workspace and uploads files to it, they will not actually see the file structure updated with the new file names. You must first close the folder and reopen it. In the screenshot above, open the script directory and then upload files to it. I think you'll see what I am describing.

@vzhukovskii There was a bug in the navigator and plugin tree views that the global selection was not cleaned properly when they are disposed. I've introduced TreeWidgetSelection to deal with that in TreeWidget. One can enable it via globalSelection props. Could you please have a look that it does not break menu items for tree view? I will do it as well.

Is this the same bug you were talking about?

Solution: Make a call to refresh the file tree after the upload process is complete.

This issue also exist when you delete a file. You have to close the folder and open it back up again to see the changes occur.

[jgbradley1]

This is not a necessary feature right now, but we should think about some way to communicate upload progress on a status bar or on the blue bar at the bottom of the page.

[akosyakov]

This is not a necessary feature right now, but we should think about some way to communicate upload progress on a status bar or on the blue bar at the bottom of the page.

It is on our list to allow blueish progress bar for different top-level widgets similar what you see in VS Code or Chrome while loading the page. It is even more important for cloud solution than for VS Code, since connection delay and issues is something which we need to deal with.

[akosyakov]

If a user has a directory open (i.e. by clicking on the drop down arrow) in the workspace and uploads files to it, they will not actually see the file structure updated with the new file names. You must first close the folder and reopen it.

It is fs watching issue. I will have a look into it. A library which we use has troubles with symlinks and does not report some events for real paths :( Refreshing for each operation is work around, it should happen automatically based on fs events.

[akosyakov]

@jgbradley1 could you try again, i've added a fix for fs watching with symlinks, cc @elaihau

[AlexTugarev]

Some random notes while testing this:

• if possible we should add a filter for all pseudo files, e.g. .app on osx, it's not a file but a folder, which is not supported, and the effect is, that it doesn't bark, but blocking the next try to upload a file for quite some time.
• maxFileSize exceeded is not reported
• files of the same name are overridden silently
  • maybe it would makes to write to orig_filename.tmp, and mv to the then computed filename.

[akosyakov]

i think we can wait till someone opens bugs for pseudo files and silent override. What would be good default maxFileSize?

[AlexTugarev]

This works nicely! 🎉

[akosyakov]

@AlexTugarev I've added proper error handling and uploadMaxFileSize env variable, by default it is 2048MB. Could you check again?

@jgbradley1 i've also added upload progress reporting :)

[elaihau]

Nice feature. i love it.
I tried uploading different versions of the same file to the same location, and found the newer version replaces the older - that's what i expected. would it be helpful if theia warns the user the older version would be overwritten ?

[akosyakov]

I tried uploading different versions of the same file to the same location, and found the newer version replaces the older - that's what i expected. would it be helpful if theia warns the user the older version would be overwritten ?

It is not easy to implement: this part of code cannot prompt to a user, since it does not go through web socket connection). We can only fail the whole request.

[jgbradley1]

@akosyakov This is great. +1 on the progress bar. Something is wrong with the max file size. It's off by an order of magnitude. I cannot upload any file > 2 MB and they all fail with the Payload too large message (tested on Gitpod). Files < 2 MB upload successfully. The math in the code looks correct however.

2048 * 1024 * 1024 (bytes) = 2 GB

[akosyakov]

@jgbradley1 good catch! thank you for checking

Updated: it turned out to be a proxy settings issue in Gitpod

[akosyakov]

@AlexTugarev @jgbradley1 I've fixed and retested locally handling of exceeded payload. It should be fine now. Good to merge?

[akosyakov]

merging, @AlexTugarev said that he is fine with changes in off-line conversation