The avatar plugin should not change the display element, since the
avatar is always shown by default and the display value is up to the
developers
Signed-off-by: Julius Härtl <jus@bitgrid.net>
When finishing the setup of Nextcloud through the WebUI (setting admin
user and database) Firefox offers to save the username and password.
However, the password was shown in both the username and password fields
of the Firefox password manager dialog.
The problem was that the password input element (in the HTML form) is
cloned in a text input element, which is used to show the password in
plain text when clicking on the "Show password" button. As it was a text
input immediately followed by a password input Firefox seemed to assume
that it had to be the username and ignored the real username field, no
matter the value set for the "autocomplete" attribute. Now the cloned
text input is added after the password input, so Firefox no longer
thinks that the cloned text input is the username field and the password
manager dialog shows the proper username instead.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
With the new avatar endpoint there is no difference between unknown
users and errors when generating the placeholder avatar. Therefore the
avatar function will now show the old placeholder if both a user and
displayname was given as parameters.
In case there is no displayname provided we cannot build the proper
placeholder so the unknown user placeholder is shown.
The displayname is not required for the avatar anymore, so we can
get rid of the old code path for placeholders.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
The js and php code differ ever so slightly. So having the placeholder
for a second and then the image is just weird.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Fixes#7574
During some refactoring the event linked to password reset got removed.
This ment that we just submitted a normal POST but without the CSRF
token. And none of the js magic to redirect afterwards.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
When a Snap was disabled it stopped listening to the events, but if a
drag gesture was being performed it was kept as active. Thus, when the
Snap was enabled again move events were handled as if the Snap had never
been disabled, causing the gesture handling to continue where it was
left.
When the Snap for the navigation bar is disabled by an app it could be
as a result of a different gesture being recognized by the app (for
example, a vertical swipe) once both gestures have started. In that case
when the other gesture ends and the Snap is enabled again any pointer
movement will cause the navigation bar to slide until an "up" event is
triggered again (obviously not the desired behaviour).
Due to all this now when the Snap for the navigation bar is disabled by
an app the current drag gesture for the navigation bar is ended.
Note that this was added as a parameter to "Snap.disable()" instead of
done unconditionally to keep back-compatibility with the previous
behaviour (probably not really needed as it is unlikely that any app is
using the Snap library relying on that behaviour... but just in case).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
On narrow screens a slide gesture can be used to open or close the
navigation bar. However that gesture could conflict at times with the
gestures used by certain apps (for example, if the right sidebar is open
the user may expect to close it by dragging it to the right, but that
could open the navigation bar instead depending on how the events are
handled). This commit makes possible for apps to disallow and allow
again that slide gesture.
In any case, note that applications can only disallow the gesture,
but they can not enable it. That is, they can prevent the gesture from
being used on narrow screens, but they can not make the gesture work on
wide screens; they are always limited by the base rules set by the core.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The slide gesture is enabled or disabled depending on the width of the
browser window. In order to easily control that width the karma-viewport
plugin is now used in the unit tests.
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>
the contacts popovermenu is also present and is being replaces, ending
up in two permission popupmenus with checkboxes duplicating the id,
breaking further permission changes.
plus, fixing a selector
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
In case of error, instead of a generic error message, an upload will
display whichever message is returned in the Sabre Exception, if
applicable.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Fixed transition bug of grouptop
Fix password submit and error handling
Fixed multiple form send
Fix submit loading state
fix login form sending state
Replace loader type
Signed-off-by: John Molakvoæ (skjnldsv) <skjnldsv@protonmail.com>
This commit adds chunked uploads in the Web UI (for authenticated users,
but not for public uploads). To do that the server endpoint used by the
uploader is changed from WebDAV v1 to WebDAV v2. The chunking itself is
done automatically by the jQuery-File-Upload plugin when the
"maxChunkSize" parameter is set; in "fileuploadchunksend" the request is
adjusted to adapt the behaviour of the plugin to the one expected by
"uploads/" in WebDAV v2.
The chunk size to be used by the Web UI can be set in the
"max_chunk_size" parameter of the Files app configuration. By default it
is set to 10MiB.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Now that the permissions returned by the server specify whether a file
is readable or not the frontend no longer needs to assume that every
file is readable.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Now that these tests are executed they are revealed to be partially
obsolete; they were fixed to match the current parsing behaviour.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The first parameter of "apply" must be the object to act as "this", and
the Promise callback gets the parameters provided in the "resolve".
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Now a file gets its directory permissions only if it contained no
permissions (they were undefined or null), but not if its permissions
were set to "NONE".
Besides that, now file actions that do not require any permission on the
file to be performed can be used on files that have no permissions.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
IE11 triggers an 'input' event whenever an input is focussed
or loses focus. Thus this causes an endless loading loop as soon
as the view is re-rendered. To prevent this, this remembers the
previous search term and ignores events where the term has not
changed.
Fixes https://github.com/nextcloud/server/issues/5281
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
The seed of the image placeholder is needed to generate the background
color of the image, but as the background color is later overriden any
seed could be used. When no text is explicitly given the seed is used as
text too, so there is no need to pass the user ID and simply using "?"
as seed is enough.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When calling the jQuery avatar plugin with a user that did not exist
(that is, users for which "/avatar/{user}/{size}" return a JSON response
with an empty "displayname" value) "?" on a grey background was shown.
However, if the jQuery avatar plugin was called with an undefined
JavaScript value then "?" was shown on a bluish background. This commit
unifies both cases to use the grey background.
The unit tests were also modified to ensure that the grey background is
used in both cases.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
If the share input field is unfocused, the autocomplete list is closed. Once
the field was focused again it was not properly opened again. This adds a
trigger to redo the search and show the results again.
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
The pure CSS loading icon uses an ::after pseudo-element, and thus it
can only be used on container elements; the input element is not a
container element, so when the class "icon-loading-small" is set on an
input element it falls back to a loading icon GIF.
This commit modifies the markup of the login button to add a div element
that holds the confirm icon and the loading icon (depending on the
case). In order to position the icon in the same place as before the
input and the icon are both wrapped by another div making possible to
set the absolute position of the icon relative to the input.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"select2-toggleselect.js" provides an extension to Select2 that makes
possible to unselect items in a multi-select dropdown by clicking on
them. It seems that its load slipped through when moving things around
in commit 6a470e59356b8c52115fe2790666027f38977604; this commit adds it
to the JavaScript files to be loaded in the same position that it should
have had in that commit (based on how the other declarations were
moved).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The sort comparator checks the "isFavorite" property of the FileInfo
objects to compare. That property is set when the file list is loaded
and the response from the server is parsed, and thus a freshly loaded
file list has the proper sorting for favorite files. However, the
property is not set in other cases, like when the FileInfo objects are
derived from FileInfoModels due to a file being marked as a favorite or
a text editor being closed, which causes the file to be sorted in the
wrong position.
There is no need to add the property in those situations, though; in all
cases the TagsPlugin adds a "tags" array property that contains an
OC.TAG_FAVORITE tag, so that tag can be checked instead of "isFavorite".
Moreover, although "isFavorite" was added by the main "_parseFileInfo"
function it did not really belong there but to the "FileInfoParser" from
the TagsPlugin; however, as that property now is not used anywhere it
was removed altogether.
A cleaner solution would have been to make the sort comparator
extensible by plugins like other behaviours of the file list and then
add the sorting logic related to favorite files to the TagsPlugin.
However, right now only the TagsPlugin would need to alter the main
sorting logic, and it seems like a corner case anyway. Even if it is
implemented as a plugin, favorite files is a core feature, so for the
time being it will be taken into account directly in the main sorting
logic; making the sort comparator extensible by plugins is defered until
there are other use cases for that.
Fixes#5410
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Julius Härtl
Morris Jobke
John Molakvoæ (skjnldsv)
Daniel Calviño Sánchez
splitt3r
Arthur Schiwon
Bjoern Schiessle
Roeland Jago Douma
Tobias Kaminsky
Allan Nordhøy
Jan-Christoph Borchardt
Lukas Reschke
Vincent Petry
Roeland Jago Douma
Marin Treselj
Markus Staab
Thomas Bille
Christoph Wurst
Thomas Citharel
Thomas Ebert
Maxence Lange
Robin Appelman
Joas Schilling