summaryrefslogtreecommitdiffstats
path: root/apps/files/js/file-upload.js
Commit message (Collapse)AuthorAgeFilesLines
* refs #11864 handle empty dir drop in Files UIJulien Veyssier2021-11-081-0/+6
| | | | Signed-off-by: Julien Veyssier <eneiluj@posteo.net>
* Fix bug introduced on drag and drop external filespjft2021-10-171-1/+6
| | | | | | | | | | | | | | | | | | Drag and drop of external (OS filesystem) to subdirectories in the browser would fail on specific cases, mainly when the subdirectory was no longer off the root folder. This seemed to have been an issue introduced with the subdirectory free space calculation [here](https://github.com/nextcloud/server/commit/f9536b08096ed1c80391af36d33a18198be1fced) and it seems to fail for any subdirectory that doesn't belong to the root folder. Bug reports: - https://help.nextcloud.com/t/drag-drop-into-subfolders/120731 - https://github.com/nextcloud/server/issues/24720 I couldn't find any reference on scenarios or quota management that would suggest when a subdirectory's free space would be different to the parent's free space, other than when on the root folder, where subdirectories can be external mounts. As such, if my understanding is correct (please review), this calculation can - and should - be made by getting the free space from the first subdirectory in the total path, which caters for all subdirectory scenarios. Please advise, happy to help improve this. Co-authored-by: John Molakvoæ <skjnldsv@users.noreply.github.com> Signed-off-by: pjft <pjft@users.noreply.github.com>
* file-upload: Correctly handle error responses for HTTP2Jakub Onderka2021-10-061-1/+1
| | | | Signed-off-by: Jakub Onderka <ahoj@jakubonderka.cz>
* Change the concurrent upload limit to less than 10szaimen2021-08-091-1/+1
| | | | Signed-off-by: szaimen <szaimen@e.mail.de>
* Fix total upload size overwritten by next uploadDaniel Calviño Sánchez2020-12-231-1/+4
| | | | | | | | | | | | | | | | | | | The upload progress is based on the "totalToUpload" variable. However, as the variable is set when an upload is submitted, if another upload is submitted before the previous one finished the upload progress only took into account the size of the new upload (although the upload itself worked fine; the files of the new submitted upload are added to the active one). Now "totalToUpload" is either increased or set depending on whether an upload is active or not. Note that although "data.total" holds the total size of the files being uploaded "totalToUpload" needs to be used in "fileuploadprogressall" instead; "totalToUpload" is calculated when the upload is submitted, but since 7c4c5fe6ae91 the actual upload of the files, and thus updating the value of "data.total", may be deferred until the parent folders were created. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
* Check for target folder available quota when uploadingJulius Härtl2020-11-171-3/+10
| | | | | Signed-off-by: Julius Härtl <jus@bitgrid.net> Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
* Better error message when blocked by access controlJoas Schilling2020-09-041-0/+2
| | | | Signed-off-by: Joas Schilling <coding@schilljs.com>
* Fix IE11 upload fallback methodsJohn Molakvoæ (skjnldsv)2020-04-221-2/+26
| | | | Signed-off-by: John Molakvoæ (skjnldsv) <skjnldsv@protonmail.com>
* Remove deprecated global variablesChristoph Wurst2020-03-091-6/+6
| | | | Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
* Also set X-OC-Mtime header for files that are smaller than 10MBJulius Härtl2019-11-071-0/+4
| | | | Signed-off-by: Julius Härtl <jus@bitgrid.net>
* Comply to eslintJohn Molakvoæ (skjnldsv)2019-10-011-5/+5
| | | | Signed-off-by: John Molakvoæ (skjnldsv) <skjnldsv@protonmail.com>
* Update file-upload.jsValdnet2019-05-091-1/+1
| | | Change the location of the translation file.
* [app:files] Use current directory for hashing.Evilham2019-03-131-4/+3
| | | | | | | | | | This fixes collisions that were causing uploads to break in a very terrible way. Kudos to @kesselb for finding the problematic place and to @hottwister for the proposed solution. Fixes #10527.
* Limit number of simultaneous MKCOL requests to server to increase upload ↵Tomasz Grobelny2019-02-161-18/+23
| | | | | | reliability Signed-off-by: Tomasz Grobelny <tomasz@grobelny.net>
* Merge branch 'master' into operation_progress_improvements3Tomasz Grobelny2019-01-291-5/+8
|\ | | | | | | Signed-off-by: Tomasz Grobelny <tomasz@grobelny.net>
| * Fix dropping a folder on a folder rowDaniel Calviño Sánchez2019-01-291-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the uploaded files have a relative path (that is, when a folder is uploaded) it is first ensured that all the parent folders exist, which is done by trying to create them. When a folder is created in the currently opened folder the file list is updated and a row for the new folder is added. However, this was done too when the folder already existed, which caused the previous row to be removed and a new one added to replace it. For security reasons, some special headers need to be set in requests; this is done automatically for jQuery by handling the "ajaxSend" event in the document. In the case of DAV requests, if the headers are not set the server rejects the request with "CSRF check not passed". When a file or folder is dropped on a folder row the jQuery upload events are chained from the initial drop event, which has the row as its target. In order to upload the file jQuery performs a request, which triggers the "ajaxSend" event in the row; this event then bubbles up to the document, which is then handled by adding the special headers to the request. However, when a folder was dropped on a folder row that folder row was removed when ensuring that the folder exists. The jQuery upload events were still triggered on the row, but as it had been removed it had no parent nodes, and thus the events did not bubble up. Due to this the "ajaxSend" event never reached the document when triggered on the removed row, the headers were not set, and the upload failed. All this is simply fixed by not removing the folder row when trying to create it if it existed already. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
| * Throttle getstoragestats.php calls and allow simultaneous uploadsTomasz Grobelny2019-01-271-1/+2
| | | | | | | | Signed-off-by: Tomasz Grobelny <tomasz@grobelny.net>
| * apps: file-upload: fix typo in commentsTigran Mkrtchyan2019-01-211-2/+2
| | | | | | | | Signed-off-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
| * Do not show general warning on free space errorRoeland Jago Douma2018-12-051-1/+1
| | | | | | | | | | | | | | | | Fixes #12588 Probably needs more fixing for the other cases. But this is the quick fix I could come up with for now. Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
* | Move progress bar to separate componentTomasz Grobelny2018-11-241-22/+12
| | | | | | | | Signed-off-by: Tomasz Grobelny <tomasz@grobelny.net>
* | Restructuring code in file-upload.jsTomasz Grobelny2018-11-241-27/+37
|/ | | | Signed-off-by: Tomasz Grobelny <tomasz@grobelny.net>
* Ask before cancelling an ongoing uploadJohn Molakvoæ (skjnldsv)2018-11-051-5/+24
| | | | Signed-off-by: John Molakvoæ (skjnldsv) <skjnldsv@protonmail.com>
* Do not hide the progress bar while the chunked upload is being assembledDaniel Calviño Sánchez2018-09-071-1/+48
| | | | | | | | | | | | | | | Large files are not uploaded in a single operation, but uploaded in several chunks; once all the chunks are uploaded then the server needs to assemble them to get the final file. Before, once the chunks were uploaded the progress bar was hidden. However, this was confusing for the users, as the file could still need some time to appear in the file list due to the assembling. Now once all the chunks are uploaded the text in the progress bar changes to inform the user that there are still some pending operations, and only when the file is finally assembled the progress bar is hidden. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
* Do not show an error message when draging and dropping textDaniel Calviño Sánchez2018-06-081-0/+10
| | | | | | | | | | | When the browser reports a drag of items other than files (for example, text) and then triggers a drop event with no files no error message should be shown to the user, as in that case there would be no highlight of the drop zone and no indication that the drop would be valid (except for the mouse cursor); the error message should be shown only when the drop event with no files follows a file drag. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
* Remove no longer needed special handling for FirefoxDaniel Calviño Sánchez2018-06-081-15/+8
| | | | | | | | | | The highlighting was removed in Firefox when the cursor was no longer moving to handle the behaviour of reporting a file drag and then providing no files in the drop event. That behaviour (which was only present in Firefox 48 and 49) is already handled with the "dropnofiles" callback, so that special handling is no longer needed. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
* Use "dropnofiles" callback to disable the drop state in the UIDaniel Calviño Sánchez2018-06-081-0/+10
| | | | | | | | | | | | | | | | | | When a file is dragged from the desktop to the file list the file list is highlighted, and when the file is finally dropped or the drag operation is cancelled the highlighting is removed. In some cases, due to a wrong implementation, a browser may end a file drag with a drop with no files (for example, when a folder or text is dragged), which would cause the highlight to not be removed. Now those cases are handled with the "dropnofiles" callback, which restores the UI and also shows a message to the user. The error message is just a generic one, as in some cases it is not even possible to know whether the problem came from a text drag or a folder drag, and whether the problem appears or not depends on the browser, version and even operating system. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
* Remove duplicated codeDaniel Calviño Sánchez2018-06-081-6/+1
| | | | | | | "disableDropState" was set as the event handler in 8d4e5747f386a0, but the duplicated code was accidentally added back in 786e858d23c4a4. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
* Fix race condition when preparing upload folderDaniel Calviño Sánchez2018-04-221-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | Before any upload is submitted the upload is registered in a list of known uploads; this is needed to retrieve the upload object at several points of the upload process. When a chunked upload is submitted first a directory to upload all the chunks is created and, once that is done, the chunks are sent; in order to send a chunk the upload object needs to be retrieved from the list of known uploads. When all the active uploads were finished the list of known uploads was cleared. However, an upload is not active until it actually starts sending the data, so while waiting for the upload directory to be created the upload is already in the list of known uploads yet not active. Due to all this, if the active uploads finished while another pending upload was waiting for the upload directory to be created that pending upload would be removed from the list of known uploads too, and once the directory was created and thus the chunks were sent a field of a null upload object would be accessed thus causing a failure. Instead of removing all the known uploads at once when the active uploads finish now each upload is explicitly removed when it finishes. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
* Fix progress bar hidden before the upload endsDaniel Calviño Sánchez2018-04-051-7/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The jQuery File Upload plugin triggers the "stop" event once there are no more files being uploaded (even if some of them were added when another upload was already in progress). Therefore, the progress bar should be hidden in the "fileuploadstop" callback. In some cases the "stop" event is not triggered and thus the progress bar is not hidden once no more files are being uploaded. This is caused by a race condition and it will be fixed in another commit; except in buggy cases like that one (that need to be fixed anyway) it is safe to hide the progress bar in the "fileuploadstop" callback. In any case, note that the callbacks in "fileuploaddone" may be called after the "stop" event was triggered and handled when using chunked uploads. In that case once all the chunks are uploaded the assembled file is moved to its final destination, so its promise could be resolved after the "stop" event was triggered. Therefore a different approach would be needed to keep the progress bar visible until the chunked upload is truly finished, but for the time being the current one is good enough. Before this commit the progress bar was being hidden when the first upload finished, either successfully or with an error, no matter if there were other files being uploaded too. The progress bar was being explicitly hidden also when the upload was cancelled. When an upload is cancelled all the single uploads are aborted, which triggers a "fail" event for each of them. However, the "stop" event is always triggered when no more files are being uploaded, so it is triggered too once all the single uploads were aborted. As all the single uploads are immediately aborted in a loop when the general upload is cancelled it makes no difference to hide the progress bar when the first single upload is aborted or when all the single uploads were aborted, so the progress bar is no longer explicitly hidden in the former case. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
* Don't encode paths passed to the OC.Files.ClientRoeland Jago Douma2018-01-101-7/+7
| | | | | | | This is handled already in the client. So double encoding breaks things in some situations. Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
* Merge pull request #7533 from ↵Morris Jobke2018-01-031-1/+12
|\ | | | | | | | | nextcloud/oc-28545-handle-oc-total-length-in-new-chunking [oc] Handle OC-Total-Length in new chunking
| * Only set X-OC-Mtime when browser provided lastModified on uploadVincent Petry2017-12-151-4/+12
| | | | | | | | Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
| * Transmit OC-Total-Length in browser as wellThomas Müller2017-12-151-1/+4
| | | | | | | | Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
* | Update quota on file upload and deletionJohn Molakvoæ (skjnldsv)2017-12-211-1/+1
|/ | | | Signed-off-by: John Molakvoæ (skjnldsv) <skjnldsv@protonmail.com>
* Parse Sabre Exception in OC.Files.Client and file-uploadVincent Petry2017-11-131-6/+29
| | | | | | | | In case of error, instead of a generic error message, an upload will display whichever message is returned in the Sabre Exception, if applicable. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
* Enable chunking for bigger files in authenticated web uploadVincent Petry2017-11-031-12/+59
| | | | | | | | | | | | | | | | This commit adds chunked uploads in the Web UI (for authenticated users, but not for public uploads). To do that the server endpoint used by the uploader is changed from WebDAV v1 to WebDAV v2. The chunking itself is done automatically by the jQuery-File-Upload plugin when the "maxChunkSize" parameter is set; in "fileuploadchunksend" the request is adjusted to adapt the behaviour of the plugin to the one expected by "uploads/" in WebDAV v2. The chunk size to be used by the Web UI can be set in the "max_chunk_size" parameter of the Files app configuration. By default it is set to 10MiB. Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
* Add space between ellipsis and wordMorris Jobke2017-10-251-2/+2
| | | | Signed-off-by: Morris Jobke <hey@morrisjobke.de>
* Update file-upload.jsrakekniven2017-10-071-2/+2
| | | Fixed tiny translation issues. Removed space before ellipsis.
* Don't try the actual file upload if the checks already error outRoeland Jago Douma2017-08-261-0/+3
| | | | Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
* Replace ... with …Morris Jobke2017-08-231-3/+3
| | | | Signed-off-by: Morris Jobke <hey@morrisjobke.de>
* Show "Uploading..." in web UI for long uploadsMorris Jobke2017-08-231-0/+4
| | | | | | | | If the estimated upload time is bigger than 4 hours it shows the text "Uploading..." because the time then doesn't give any good hint to the user anyways. Signed-off-by: Morris Jobke <hey@morrisjobke.de>
* Fix uploadrate value of 'original-title' attributeBekcpear2017-06-161-1/+1
| | | | | | | The unit of `data.bitrate` is bit, but the argument unit of `humanFileSize` function is byte, so it should be divided by 8. Signed-off-by: Yaojin Qian <i@ume.ink>
* Fix upload remaining timeBekcpear2017-06-161-12/+14
| | | | | | | | | | | | | The upload remaining time is always 'a few second' whatever a big or a small file uploading. This commit fixes it. The `new Date().getMilliseconds()` only return a three digits number. When time arrived the next second, the millisecond start from ZERO again. So `new Date().getTime()` is the righe choice. And remaining time variables shoule be initialized when the file starts uploading, otherwise the remaining time of a new upload will always be 'Infinity years' until you refresh the page. Signed-off-by: Yaojin Qian <i@ume.ink>
* Remove dependency on jquery-migrate.js for browser detectionMorris Jobke2017-05-011-1/+1
| | | | | | * ref #4628 Signed-off-by: Morris Jobke <hey@morrisjobke.de>
* Merge pull request #4153 from nextcloud/fix-uploadJoas Schilling2017-04-061-1/+2
|\ | | | | Fix upload of folders in Chrome
| * Fix upload of folders in ChromeMorris Jobke2017-04-061-1/+2
| | | | | | | | Signed-off-by: Morris Jobke <hey@morrisjobke.de>
* | Some more hardeningJoas Schilling2017-04-041-6/+7
| | | | | | | | Signed-off-by: Joas Schilling <coding@schilljs.com>
* | file-upload.js modified : Remaining upload time correctedSarthikaDhawan2017-04-041-1/+10
|/ | | | Signed-off-by: Morris Jobke <hey@morrisjobke.de>
* added quit option in commentstabview.jsnoveens2017-03-231-11/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | added quit option in notif in app.js added quit option in notif in file-upload.js added quit option in notif in fileinfomodel.js added quit option in notif in filelist.js added quit option in notif in filelist.js added quit option in notif in tagsplugin.js added quit option in notif in statusmanager.js added quit option in notif in external.js added quit option in notif in versionstabview.js added quit option in notif in notification.js changes according to the latest review. timeout removed since there is a button to close it translation capability added typo fixed test files updated small errors fixed Signed-off-by: Morris Jobke <hey@morrisjobke.de>
* dont preserve mtime when uploading trough the web interfaceRobin Appelman2017-03-131-5/+0
| | | | Signed-off-by: Robin Appelman <robin@icewind.nl>
generated by cgit v1.2.3 (git 2.39.1) at 2025-02-05 03:09:08 +0000