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>
"FileList._updateDetailsView" expects either a file name (as a string)
or a file model (as an "OCA.File.FileInfoModel"), but when called
through "updateInList" an "OC.Files.FileInfo" object was given instead.
As the given attribute was not a model "_updateDetailsView" treated it
as a file name and tried to get the model for that file, which failed
and caused the details view to be emptied.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the favourite icon in the details view is clicked the "Favorite"
action is triggered. However, if the action name given to
"triggerAction" is not found then the "Download" action is triggered
instead. As the "Favorite" action is not available in some file lists
(like "Recents") the "Download" action was executed instead in those
cases, which was a strange behaviour. Now the favourite icon is
hidden if its action is not available.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a file from the file list is dragged a drag shadow (a copy of the
file row that follows the cursor position) is created. The drag shadow
element is created as a direct child of the body element, so it needs a
higher "z-index" than the one used for the file list to be visible.
In narrow screens the "#app-content" uses a "z-index" of 1000 in order
to be visible over the "#navigation-bar" when they overlap, so the
"z-index" of the drag shadow must be at least 1000 to be visible over
the file list.
Instead of updating the hardcoded "z-index" it was removed and replaced
by CSS rules for ".dragshadow" elements to ease theming.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
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>
1. 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.
2. 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>
The post-render event makes possible to modify the
MainFileInfoDetailsView element once it has been rendered, which is
needed by OCA.SystemTags.FilesPlugin to add the "Tags" label to the file
details, while the pre-render event makes possible to detach added
elements if needed before the MainFileInfoDetailsView is rendered again,
as that removes the events from the child DOM elements even if they
belong to other views.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In some cases, an app may need to act on a detail view registered by
another app or the core, for example, to add extra elements to the
element of the detail view.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Fixes: #4644
Without this patch the filelist would always reload. However since not
all the correct data was set yet it would often:
1. fireoff a propfind to ../webdav/
2. fireoff a propfind to ../webdav/<PATH>
When just opening the file list those are the same so the result is just
fine. However if opening a direct link it means that there is a race
condition on which finishes first.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Whenever a file list is already initialized and was hidden when
switching to another file list in the navigation bar, if the user comes
back to this list it gets redisplayed. At this point the list needs to
be refreshed to be able to reflect any potential file changes done from
the other lists.
The Files app active view is set to "files" in silent mode to avoid an
unneeded load of the "/" directory. However, this also prevents the
details view from being automatically closed, so it has to be explicitly
closed by the Goto plugin; the approach used is the same that would have
been used by OCA.Files.App._onNavigationChanged if not silenced.
Fixes#1448
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The local link is a clever thing and the clients should support this imho but it might not be clear to all users. For one, the term 'local link' is a bit odd. Local with respect to what? It links directly to the file or folder, so direct link seems to make more sense to me. And we should explain the difference with a public link. So this PR:
* renames local link to direct link
* adds a short explanation, noting it only works for users who have access to this file/folder.
As other links are called public link you could also consider calling this 'private link', I suppose. But the links we sent by mail to ppl could also be called 'private link' (they are for one user, who git it by email) so I think it might be confusing. What do @nextcloud/designers think?
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
Daniel Calviño Sánchez
Morris Jobke
Robin Appelman
Bernd Stellwag
rakekniven
Roeland Jago Douma
Roeland Jago Douma
Yaojin Qian
Joas Schilling
Patrik Kernstock
Phil Davis
Jan-Christoph Borchardt
Julius Härtl
Vincent Petry
Jos Poortvliet
Michael Jobst
SarthikaDhawan
Lukas Reschke