Now this is in core so the basics (that 99% of the app will want to
use) looks always the same.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
When a "mouseup" event was triggered on any element except on the share
menu or its descendants the share menu was closed. The share menu toggle
is not a descendant of the share menu, so clicking on it when the share
menu was shown closed it by removing its "open" CSS class. However, once
that happened the click event was then handled by the share menu toggle,
which toggled the "open" CSS class in the share menu and thus added it
again. So, from the user point of view, nothing happened when clicking
on the share menu toggle if the share menu was open.
Now a "mouseup" event on the share menu toggle no longer closes the
share menu, and thus toggling the "open" CSS class when handling the
"click" event works as expected.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
fileInfo is composed of data from sharing, however additional data is
pulled when sidebar opens, e.g. the size. Then, existing data is
overwritten by data from the other source (files). The data points that
would be lost are not dirty however and still used, so we keep them.
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
As "singleFileUpload" is used the "add" callback (which in turn calls
"addFileToUpload") will always be called with a single file. Therefore
there is no need to iterate over the files (and it is not done in the
other callbacks either, so this aligns the code with the rest of the
callbacks).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
There is no need to store the file name, as the "data" parameter given to
all the callbacks provides a "files" attribute with all the files that
the callback refers to; moreover, it will always be a single file due to
the use of "singleFileUploads" in the jQuery File Upload plugin.
This also fixes the loading icon not disappearing when several files were
uploaded at once. "singleFileUploads" causes the "add" callback to be
called once for each file to be uploaded, so "fileName" was overwritten
with the name of each new file in the upload set; when "fileName" was
later used in the "done" callback to find the file in the list whose
loading icon replace with the MIME type icon "fileName" always had the
name of the last file, and thus its icon was the only one replaced.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The "done" and "fail" callbacks both update the item for the uploaded
file using "setFileIcon". "setFileIcon" updates the contents of the
"<li>" element for the file, but the "fail" callback was giving
"setFileIcon" an element generated by the template, so the resulting
HTML contained a "<li>" element nested in another "<li>" element.
However, generating the HTML is better done through a template, so the
template now receives the icon to show in order to be used by a
successful upload and a failed one, and "setFileIcon" was changed to
"updateFileItem".
Note that the mimeTypeUrl does no longer need to be escaped, as
Handlebars templates escape the needed characters automatically.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the "fail" callback is called, "errorThrown" is a property of the
data object instead of a parameter.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Fixes#4248
The magic introduced in #3686 caused the shared views not to be updated
properly. Thus we just overwrite the _onUrlChange method in the
sharedfilelist.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
John Molakvoæ (skjnldsv)
Björn Schießle
Daniel Calviño Sánchez
MartB
Julius Härtl
Morris Jobke
Roeland Jago Douma
Arthur Schiwon
Jan-Christoph Borchardt
Artur Neumann
Vincent Petry
Joas Schilling
Michael Jobst