| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
nextcloud/stable13-9245-fix-race-condition-when-preparing-upload-folder
[stable13] Fix race condition when preparing upload folder
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |/ |
|
| |\
| |
| |
| |
| | |
nextcloud/backport/9224/accessibility-improvements-13
[stable13] Add labels for Contacts menu and Settings
|
| | |
| |
| |
| | |
Signed-off-by: Jan-Christoph Borchardt <hey@jancborchardt.net>
|
| |/ |
|
| |
|
|
| |
Signed-off-by: Julius Härtl <jus@bitgrid.net>
|
| |
|
|
| |
Signed-off-by: Julius Härtl <jus@bitgrid.net>
|
| |
|
|
| |
Signed-off-by: Julius Härtl <jus@bitgrid.net>
|
| | |
|
| | |
|
| |
|
|
| |
Signed-off-by: John Molakvoæ (skjnldsv) <skjnldsv@protonmail.com>
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
| |
|
|
| |
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
| |
|
|
| |
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
| |
|
|
| |
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
| |
|
|
| |
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
| |
|
|
| |
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
| |
|
|
| |
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
| | |
|
