Fixes#7697
When using the new login flow a token will be generated since we login.
However after that we generate yet another token to return (as we
should).
However we should kill the current session token as we are done with it.
And will never use it again.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
* unify shadow blur from 3px to 10px
* remove opacity of background of app labels
* for IE: use box-shadow as fallback (because the filter: drop-shadow is not supported)
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
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>
".popovermenu" elements are visible or not depending on whether they
also have the "open" CSS class or not. "#header .menu" elements were
always hidden, so when both rules applied to the same element, like in
the menu of a Share page, the element was always hidden due to
"#header .menu" being more specific than ".popovermenu" and thus
overriding its rules. Now, "#header .menu" elements are hidden only if
they are not a ".popovermenu" too.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
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>
Morris Jobke
Roeland Jago Douma
John Molakvoæ (skjnldsv)
Julius Härtl
Nextcloud bot
splitt3r
Roeland Jago Douma
Arthur Schiwon
Bjoern Schiessle
John Molakvoæ
Marin Treselj
Daniel Calviño Sánchez