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>
OCA.Sharing.SharedFileInfo was never defined and that stopped execution.
Interestingly, FF never showed me an error.
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
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>
John Molakvoæ (skjnldsv)
Morris Jobke
Daniel Calviño Sánchez
Roeland Jago Douma
Stefan Weil
Julius Härtl
Roeland Jago Douma
Christoph Wurst
Arthur Schiwon
Björn Schießle
MartB