Before, whenever a pending operation (getting the suggestions,
confirming a share or selecting a recipient) finished the working icon
was hidden and the confirm button was shown again, even if there were
other pending operations (the most common case is typing slowly on the
input field, as several operations to get the suggestions could pile if
the server response is not received fast enough). Now, the working icon
is not hidden until the last pending operation finishes.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a share is confirmed the suggestions are got to check if there is
an exact match. Usually the suggestions were already got with the same
parameters in order to fill the autocomplete dropdown, so to avoid a
superfluous request now the last suggestions are reused when got again,
although only if the same parameters as the last time are used.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Besides confirming a share by clicking on the confirm button now it is
possible to do it by pressing enter on the input field.
Clicking on the confirm button implicitly hides the autocomplete
dropdown. On the other hand, pressing enter on the input field does not,
so the autocompletion must be disabled and closed when the confirmation
begins and then enabled again once it finishes. Otherwise the
autocomplete dropdown would be visible and it would be possible to
interact with it while the share is being confirmed.
The order in which the input field and the autompletion are disabled is
important. Internally, the autocompletion sets a timeout when the input
field is modified that requests the suggestions to the server and then
shows them in the dropdown. That timeout is not cancelled when the
autocompletion is disabled, but when the input field loses its focus and
the autocompletion is not disabled. Therefore, the input field has to be
disabled (which causes it to lose the focus) before the autocompletion
is disabled. Otherwise it could happen that while a share is being
confirmed the timeout ends, so an autocompletion request is sent and
then, once the share is successfully confirmed and thus the
autocompletion is enabled again, the request is received and the
autocomplete dropdown is shown with the old suggestions. Strange, but
possible nevertheless ;-)
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Clicking on the confirm button now adds a share, but only if there is
just a single exact match. If there are no exact matches or there is
more than one exact match no share is added, and the autocomplete
dropdown is shown again with all the suggestions.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"_getSuggestions" returned all the suggestions from the server, which
are composed by exact matches and partial matches. Now the exact matches
are also returned on their own parameter. This will be used by the
button to confirm a share.
Note that until now the order of the suggestions was "exact users,
partial users, exact groups, partial groups, exact..."; this commit also
changes that order to become "exact users, exact groups, exact...,
partial users, partial groups, partial...". This is not a problem, as
the suggestions were used in the autocomplete dropdown, and this new
order is arguably better than the old one, as all exact matches appear
now at the beginning.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Instead of silently failing now an error is shown to the user when the
ajax call to get the suggestions succeeds yet it returns failure content
(for example, if an "OCSBadRequestException" was thrown in the server).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"OC.Notification.hide" expects the notification to be hidden to be
passed as an argument. As it was being used to show a temporary
notification the combination of "OC.Notification.show" and
"OC.Notification.hide" was replaced by a single call to
"OC.Notification.showTemporary".
The timeout could have been specified in the options of the call, but it
was left to the default value (7 seconds) for consistency with other
notifications.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Stubs should be restored outside the test method in which they are used
to ensure that they are properly restored no matter the result of the
test (for example, if an exception is thrown).
Besides that, this will make possible to reuse the stub in other sibling
tests without having to explicitly setup it in them.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
As the server response is faked the search term is ignored in the tests.
However, it is clearer to use a search term that would make the server
return what the faked response contains.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The confirmation button right now is just an icon; its behaviour will be
added in the following commits.
Signed-off-by: Jan-Christoph Borchardt <hey@jancborchardt.net>
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 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>
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>
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>