Failure:
This breaks in multilingual site the automatic language change with the error:
Call to undefined method Joomla\CMS\Language\Language::setLanguage()

Call stack
--
# | Function | Location
1 | () | JROOT/plugins/system/languagefilter/languagefilter.php:726
2 | PlgSystemLanguageFilter->onUserLogin() | JROOT/libraries/src/Plugin/CMSPlugin.php:287
3 | Joomla\CMS\Plugin\CMSPlugin->Joomla\CMS\Plugin\{closure}() | JROOT/libraries/vendor/joomla/event/src/Dispatcher.php:400
4 | Joomla\Event\Dispatcher->dispatch() | JROOT/libraries/src/Application/EventAware.php:111
5 | Joomla\CMS\Application\WebApplication->triggerEvent() | JROOT/libraries/src/Application/CMSApplication.php:819
6 | Joomla\CMS\Application\CMSApplication->login() | JROOT/libraries/src/Application/SiteApplication.php:716
7 | Joomla\CMS\Application\SiteApplication->login() | JROOT/components/com_users/Controller/UserController.php:122
8 | Joomla\Component\Users\Site\Controller\UserController->login() | JROOT/libraries/src/MVC/Controller/BaseController.php:734
9 | Joomla\CMS\MVC\Controller\BaseController->execute() | JROOT/libraries/src/Dispatcher/ComponentDispatcher.php:146
10 | Joomla\CMS\Dispatcher\ComponentDispatcher->dispatch() | JROOT/libraries/src/Component/ComponentHelper.php:380
11 | Joomla\CMS\Component\ComponentHelper::renderComponent() | JROOT/libraries/src/Application/SiteApplication.php:211
12 | Joomla\CMS\Application\SiteApplication->dispatch() | JROOT/libraries/src/Application/SiteApplication.php:250
13 | Joomla\CMS\Application\SiteApplication->doExecute() | JROOT/libraries/src/Application/CMSApplication.php:233
14 | Joomla\CMS\Application\CMSApplication->execute() | JROOT/includes/app.php:63
15 | require_once() | JROOT/index.php:36

Looks like this happens only when using the module, not a login menu item.

hmm. Tested again today.
Looks like this is unrelated.

Yeah, setLanguage is deprecated... Which means the issue is not only in languagefilter...
\JLog::add(__METHOD__ . ' is deprecated. Instantiate a new Language object instead.', \JLog::WARNING, 'deprecated');

I have tested this item ✅ successfully on e293a43

What about the password box in the installation process? these need doing too :)

@dgrammatiko Thank you for this work. I think this is a great addition and I welcome this feature in the registration form. However I disagree with using this in any form of login screen. My main issue is the button to display the cleartext password. I see this as a security issue, which can easily disclose your password to others. I see several scenarios:

• People standing behind you unnoticed
• A person sitting at your PC and asking you to type in your password and then you handing over the controls to that other person again
• In a teamviewer session where you give control to another person

In all these cases, this feature might disclose your password to someone else and thus I would like to see this not included in the logins, at least not by default.

@Hackwar actually the password show/hide button should be a progressive enhancement that must be driven from the xml with an attribute line reveal="true". BTW I just checked and half of the J3.x options for password field are not even mentioned in the documentation: https://docs.joomla.org/Password_form_field_type

All and all, I'll make the changes so that the button is xml driven and then I guess people have to decide what the defaults should be. I'm providing the functionality here, I'm not the one deciding how, when or where this should be used...

@Hackwar Time to rewrite the web then - it is a common feature

it is a common feature

originally it was a mobile oriented feature, because limitation of mobile inputs,
later it was spread everywhere :)

originally it was a mobile oriented feature

mobile IS the internet (>70% of traffic is from mobile devices)

@brianteeman It is also common, that passwords are stored in plaintext. Doesn't mean that it is a good idea.

As I said, if you think this should be part of Joomla, then don't enable it by default. What we set as default, will end up unchanged on 99% of all websites and it will also be the thing that makes the first impression on the people evaluating Joomla for their needs. I guess it is a question of if we want to aim for the hobbyiests website or for corporations. As a security conscious corporation, I would not want that on my website.

if its not going to be enabled then there really is no point in it

if its not going to be enabled then there really is no point in it

Just look at that wildly successful password strength meter on the field. Oh, wait...

@Hackwar, anyone who' extremely concious about security will immediately notice and disable it

Just look at that wildly successful password strength meter on the field.

FWIW this custom element is also taking care of that successful option ?

I'm not saying that we shouldn't use it at all. The registration is a good place where this can be demonstrated and thus people would know it, but to me this shouldn't be something that should be enabled by default in the login form.

@Hackwar login page is overridable as the rest of the Joomla, so creating an override (or even Joomla provide some sensible override files) is way to easy for anyone creating a Joomla site. And my point is if you're not able to create an override you shouldn't use Joomla, use wix or whatever because the idea of having one more switch for the field is out of the range of ridiculousness..
At some point people need to understand the Joomla will never be able to compete to wix without a proper GUI override creator...

All and all, as I said before this PR is just providing the fumctionality. Where, when or how this is used is another issue (I'm just replacing existing fields with buttons, not introducing them here ?). So please raise another issue for that, this is not the place for this discussion...

I applied this branch (git fetch origin pull/23452/head:4.0-dev-CE-password-field) and I run composer install and npm install.

It looks not always like in the pictures in this PR but all elements worked correctly.

Backend login form

<joomla-field-password reveal="true">
<input name="passwd" type="password" id="mod-login-password" autocomplete="password" aria-labelledby="mod-login-password-lbl" required>
</joomla-field-password>

Module

<joomla-field-password reveal="true">
<input id="modlgn-passwd" type="password" name="password" autocomplete="password" placeholder="Password">
</joomla-field-password>

##User edit page

<joomla-field-password reveal="true" min-length="4"     >
<input  autocomplete="password" class="validate-password-strength"   size="30" maxlength="99"   name="jform[password]" type="password" id="jform_password" value="" aria-labeledby="jform_password-lbl">
</joomla-field-password>            

Update
I checked my installation and it looks as I made a failure. I could not find the file system/webcomponents/joomla-field-password.min.js in the media folder. So I run npm install again and now everything looks fine.

I have tested this item ✅ successfully on 12f4aaf

So I've changed all the wrong SCSS parts and also updated the installation:

@wilsonge can you review/merge this?

@coolcat-creations I just realise that the backend login page and the installation are not quite in sync in terms of design. Can you decide what should be there and align those?

Also another thing that came up with this PR: as @C-Lodder and @ciar4n were doing the templates and there was a question mark on the forms markup the decision was to keep the old way, make the transaction easier (less code to tweak). The problem is that inputs SHOULD always be 100% and the container div should set a specific width according to the breakpoint or the Grid Layout. Having each and every input set to a specific width is bad. You (I mean the team that is dealing with the templates) should change this. We're not in 2010 and we shouldn't break things that are naturally responsive...

@wilsonge can we move forward with this one?

@dgrammatiko we work on something that adresses the issue of design inconsistences, @Hackwar can you look into this one if we can merge some of our code with this work?

Closing here, I guess ES5 is pretty ok for Joomla

As stated to you on private channels and for the record I’m not merging new custom elements until the existing ones stabilise which is why this has sat there (as has been the case since I first told you this last October/November)

@wilsonge whatever, this was my third and last attempt for this