To show the password in plain text "showPassword" adds a text input
after the password input and swaps their visibility depending on whether
the password has to be shown in plain text or not. In a similar way,
"strengthify" by default adds the strength bar after the input element
it was called on. Due to this, if "showPassword" is called before
"strengthify" on the same password input then the strength bar ends
between the password input and the text input, and when the text input
is shown it appears below the strength bar.
To fix this now the strength bar is added after the text input in those
places in which "strengthify" was called after "showPassword" on the
same element.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
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>
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>
"click" events are handled by several elements in user settings, and
some of them (like the edit icon in the user name) stop the propagation
of the event. Due to this the event never reaches the document and thus
the menu was not closed in those cases. "click" events are always
preceded by "mouseup" events (as "click" events are generated when
"mousedown" and "mouseup" events occur in the same element), so now the
menu is closed when a "mouseup" is received in the document.
The described problem would happen too if an element stopped the
propagation of the "mouseup" event; currently no element does that in
the user settings, so now the menu is always closed as expected.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Daniel Calviño Sánchez
Roeland Jago Douma
Nextcloud bot
Morris Jobke
Joas Schilling
Julius Härtl
splitt3r
Roeland Jago Douma
Arthur Schiwon
John Molakvoæ (skjnldsv)