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.
When a single file was dropped on the trash bin the file information was
gotten from the original element in the file list. When several files
were dropped on the trash bin the file information was gotten from the
helper elements being dragged around. The helper element also contain
the needed file information when a single file is being dragged, so the
handling was unified to always get the file information from the helper
elements.
As the handling of several files is the same as before there is still
the issue of only deleting those files shown in the drag helper instead
of all the selected files.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The "droppedOnTrash" event was being triggered when the file list was
initialized, but it should be triggered only when the user actually
drops a file on the trash bin.
Besides that, the event had no effect; only the file list handles it,
but as it was not triggered on any element it ended being triggered on
the document, and thus not handled. Moreover, even if it had been
triggered on the file list it would have been done before the handler
was set, so it would not have been handled anyway. And even if it had
been handled no data was provided, so the handler would have failed.
In conclusion, triggering the event there was not needed, and thus it
was removed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Since 6ad7f32938 SVG icons are directly embedded in "icons-vars.css", so
the starred trash icon is now loaded along with the regular trash icon
all at once. Therefore it is not needed to explicitly prefetch it using
a hidden div.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
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>
Store the last check in the session storage. (Which gets cleared on
logout). And only check once an hour.
Saves a request to the server on most requests when browsing.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
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>
Navigating to the root folder is already handled by
OCA.Files.Navigation.setActiveItem in case the view doesn't change.
Signed-off-by: Julius Härtl <jus@bitgrid.net>
When a view is rendered it should not be concerned with where it is
going to be placed in the document; in general this should be a
responsibility of the object using the view.
Moreover, when the details view is rendered it should simply prepare a
skeleton that includes the root elements provided by the plugins; those
elements will be updated by the plugins as needed when a file or a tab
is selected.
Finally, the details view should not be explicitly rendered. The
rendering removes the previous elements, but that is needed only when
the details view is in a dirty state, that is, when new plugins were
added since the last time that it was rendered. However, that dirty
state is internally handled, and the view is automatically rendered
again if needed when a file info is set.
Due to all that the details view is no longer explicitly rendered when
updating it with a different file. Also, as each file list has its own
details view, and each details view has its own element, but there can
be only one details view/sidebar element in the document, when the file
list updates the details view it also replaces the current one in the
document with its own details view if needed (that is, if it is not the
current one already).
Besides that, when the element of a details view is replaced with the
element of a different details view the old one should be detached from
the document, but never removed. Otherwise the event handlers would not
work when that element is attached again later (when changing to a
different section in the Files app and then going back to the previous
one).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
fixes#10934
Else it triggers the rendering two times. Resulting is weird state in
for example the comments. Because the comments for OLD_FILEID are
retrieved but then the model is changed to NEW_FILEID. But the old
comments still get in and get parsed.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
The custom handler for "URL changed" events were added to reload the
file list whenever the sections for favorites and shares were opened;
this was used to fix the problem of not reloading the file lists when
opening them for a second time. However, besides that the handlers were
not really necessary, and as the root of the bug was fixed in the
previous commit those handlers are now removed.
The file list for tags uses the handler for a different purpose, though,
so that one was kept.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a section is open in the Files app a "show" event is triggered.
File list objects handle that event by reloading themselves, but only
if the file list was shown at least once. However, the file list objects
of plugins are created when the "show" event is triggered for the first
time for their section; as the file list objects register their handler
for the "show" event when they are created they never handle the first
triggered "show" event, as the handler is set while that event is being
already handled. Therefore, from the point of view of the handler, the
second time that a "show" event was triggered it was seen as if the file
list was shown for the first time, and thus it was not reloaded. Now the
"shown" property is explicitly set for those file lists that are created
while handling a "show" event, which causes them to be reloaded as
expected when opening their section again.
Note that it is not possible to just reload the file list whenever it is
shown; the file list is reloaded also when the directory changes, and
this can happen when the web page is initially loaded and the URL is
parsed. In that case, if file lists were reloaded when shown for the
first time then it could be reloaded twice, one with the default
parameters due to the "show" event and another one with the proper
parameters once the URL was parsed, and the files that appeard in the
list would depend on which response from the server was received the
last.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This fixes errors from LGTM like the following one:
Variable i is used like a local variable,
but is missing a declaration.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
This fixes some recommendations from LGTM:
Avoid automated semicolon insertion (90% of all statements
in the enclosing function have an explicit semicolon).
Signed-off-by: Stefan Weil <sw@weilnetz.de>
In general the style of the tabs container should not change depending
on which tab is the currently selected one. However, this could be
needed in some very specific cases, so now the tab views can specify the
extra CSS classes to be used in their container when they are selected.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Fixes#11030
For https://github.com/orgs/nextcloud/projects/18
This template is now compiled so this no longer has to happen in the
browser. Another step towards a stricter CSP.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
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>
Before, the file or folder was opened when clicking on the name span,
but not when clicking on the link that contains the name; clicking on
the link highlighted the file and opened the sidebar, just like clicking
on the file size or date. Now clicking on the link opens the file or
folder, so the unit tests that tested clicks on the link were changed to
test clicking on the file size instead.
Signed-off-by: Jan-Christoph Borchardt <hey@jancborchardt.net>
Fix sidebar and scrollbar on content
Sidebar fixes, and sidebar-width + header-height variables
Signed-off-by: John Molakvoæ (skjnldsv) <skjnldsv@protonmail.com>
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Added icon-change on drag
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Fixed Navbar-closing in app when favorites-list is toggled on mobile
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Refactored Code
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Changed to alphabetical sorting
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Fixed deletion of folder with identical names
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Removed ability to add files to the quickaccess
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Fixed wrong path-generation when added from favorites-star
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Removed Element from navbar when favorite-star in detailview is toggled off
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Changed Quota-Text to prevent boundarybreaks
Reverted last commit
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Fixed Bad url-generation in javascript for new quickaccessitems
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Fixed vertical scrolling in sortable-list which leads to "hidden" navbar
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Removed unnessessary console logs
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Fixed Bounds in custom sorting
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Reformatted code
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Fixed horizontalscroll on sortable-list
Fixed "stuck element" where you could not switch back to the original ordering in the sortable-list
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Added FavoritesQuickaccess-Sidebar
Added Files-FavoritesQuickaccess-Toggle
Fixed CSS for SpacerElement
Removed Unnessessary Alerts and added Translations
Tried fixing initial Quick-Access Checkboxstate
Signed-off-by: fnuesse <fnuesse@techfak.uni-bielefeld.de>
Tried fixing initial Quick-Access Checkboxstate
Changed double-Quotes to single-Quotes
Revert webdavurl which was changed by mistake
Revert quota-icon which was changed by mistake
Changed the Folderhandling from custom-designed to nextcloud-NavigationManager-handling
Signed-off-by: fnuesse <fnuesse@techfak.uni-bielefeld.de>
Moved CSS-Spacerclass to apps.scss for global usage
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Renamed settings-caption in apps.scss to app-navigation-caption
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Removed old input-tag for showQuickAccess-state
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Removed old spacer element in files.scss
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
Changed style of favorites-sublist and disabled the ability to disable files-quickaccess
Signed-off-by: fnuesse <felix.nuesse@t-online.de>
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>
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>
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>
The jQuery Plugin triggers the "dragover" callback when the browser
triggers the "dragover" event and the types in their DataTransfer
include a "Files" item. It also triggers the "drop" callback when the
browser triggers the "drop" event and the list of files in its
DataTransfer is not empty.
Unfortunately some browsers may trigger "dragover" events with a
DataTransfer that includes a "Files" item and then trigger a "drop"
event with an empty list of files. When that happens the actions
performed in the "dragXXX" callbacks could be left hanging if they were
expected to be finished in the "drop" callback (for example, if the drop
zone was highlighted during the drag to be then restored when the file
was finally dropped). This commit adds the "dropnofiles" callback to be
able to handle those situations.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"disableDropState" was set as the event handler in 8d4e5747f3, but
the duplicated code was accidentally added back in 786e858d23.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
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>
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>
Julius Härtl
Roeland Jago Douma
Greta Doci
Jonathan Matthews
John Molakvoæ (skjnldsv)
Max Fichtelmann
Morris Jobke
Robin Appelman
James Lao
Christoph Wurst
Valdnet
Evilham
Joas Schilling
Tomasz Grobelny
John Molakvoæ
Christian Aigner
fnuesse
Daniel Calviño Sánchez
Christoph Wurst
imsolost
Tigran Mkrtchyan
Florian Schunk
Roeland Jago Douma
Ido Green
Stefan Weil
Alexey Pyltsyn
Jan-Christoph Borchardt
Michael Weimann
Kevin Ndung'u
fnuesse
Arthur Schiwon
Abijeet