[files] Batch actions need some kind of working in progress-feedback (loading spinner)

[hurradieweltgehtunter]

1. Create folder
2. Select multiple files
3. Move the files via drag&drop to folder

UI seems to do nothing, Dev Console shows sequential XHR MOVE requests.
-> Provide some sort of feedback to the user, that the moving process in progress.

Same goes for

• Batchaction pasting copied files
• Batchaction deleting files (Modal stays unresponsive)

[mbuonaccorsi]

The entire implementation of copy/move seems inefficient. Instead of individual requests from the browser to the server for each folder, which if the folders/files are HUGE are likely to take forever and time out, send a compact request to initiate the process and indicate what needs to be done, then have the UI poll the status for this process and provide a progress indicator with a percentage. The entire process should run server side and not need to involve the browser once initiated.

This would prevent the frequent freezes in the UI and loss of the entire copy\move operation if you were to close the tab or navigate to another folder in the UI.

[kulmann]

The entire implementation of copy/move seems inefficient. Instead of individual requests from the browser to the server for each folder, which if the folders/files are HUGE are likely to take forever and time out, send a compact request to initiate the process and indicate what needs to be done, then have the UI poll the status for this process and provide a progress indicator with a percentage. The entire process should run server side and not need to involve the browser once initiated.

This would prevent the frequent freezes in the UI and loss of the entire copy\move operation if you were to close the tab or navigate to another folder in the UI.

Under the hood it's still WebDAV - the COPY and MOVE requests are processed server side, but we need to wait for the responses. Of course we can imagine different approaches, but then there's client compatibility - e.g. Cyberduck recently added support for ownCloud Infinite Scale, which would not have been possible if we came up with a custom API. And we're proud of writing open source software and supporting open standards. That being said, contributions are always welcome! 😉

[kulmann]

This would prevent the frequent freezes in the UI and loss of the entire copy\move operation if you were to close the tab or navigate to another folder in the UI.

Oh by the way, navigating to another folder in the UI should not be a problem. Could you try that for smaller files than you are currently trying?

[mbuonaccorsi]

This would prevent the frequent freezes in the UI and loss of the entire copy\move operation if you were to close the tab or navigate to another folder in the UI.

Oh by the way, navigating to another folder in the UI should not be a problem. Could you try that for smaller files than you are currently trying?

Generally things work okay if we're talking about a smaller set of files because that takes no time to complete. But for anything that is long running, such as a large batch copy, which I am forced to do when creating a new space (no move feature into a Space) then it could take a very long time to complete.

If I navigate to another folder I can understand how the batch operation can still complete in the background, but I do lose the status bar showing that it is happening at the very top. That little animation is all we get, no details, percentage, or any way to cancel. It feels very rough and clunky.

If we're also talking about a single operation where it's an entire folder with everything within it, then I can see the operation finishing in the background even if I closed the tab because it had already started. But if it's an operation with a large number of smaller files and subfolders selected, then I do a copy, then the browser tab has to stay open for each and every subsequent request for each item to be made. If I close the tab or browser, it stops with whatever item was in flight at the time.

What this tells me is that the Web UI is in charge of orchestrating the batch operation such that it starts an operation, waits, then starts the next one, and I am saying that it would be better if that were handled by the server and didn't require the browser to be fully connected to complete the process. It would allow displaying the status in any browser, on any machine of any batch operation in progress and would also be resilient to a disconnection or closure of the browser.

It would also mean I don't have to configure my reverse proxy to allow requests to run upwards of an hour to get any large copy operations to finish.

[JammingBen]

Closing in favour of these stories:

• [web] Ensure that copy & move operations are not UI-blocking and still running in suspended tabs #10951
• [web] Ensure that trashbin delete operations are not UI-blocking and still running in suspended tabs #10952
• [web] Ensure that restore operations are not UI-blocking and still running in suspended tabs #10953

A web worker for deleting files has been implemented already via #10916.

[kulmann]

@mbuonaccorsi your observation is correct, that the web ui currently is in charge of orchestrating batch operations. We know that this is not ideal. As long as we're relying on the WebDAV protocol for file operations we can't have reasonable batch operations though. So as a first step we're improving the batch operations from the client side, meaning a) having the batch operations in separate threads so that they don't block the web ui itself and b) warning the user when attempting to close the browser although (batch/single) operations are still active.

At least for delete, restore, copy and move I see the chance to re-implement those with server side batch processing in the Libre Graph API. But for uploads we'll always stay in the web ui for the full process, because it's obviously the data transfer that is the main part of an upload, that responsibility can't be pushed to the server. ;-)