The same problem exists for passwords - reported elsewhere just add this to that issue.

#19251, #19204

@brianteeman
I am not sure if it is the same issue. We do not allow user names with an ampersand up to now. If you create an user with an ampersand in the user name via user manager, you see a warning.
This warning is because of JOOMLA/media/system/js/fields/validate.min.js

So we should decide if we want allow user names with special characters (RegExp("[<|>|"|'|%|;|(|)|&]", "i")).

Testing this again
Creating a user in the backend fails with the correct error message

Creating a user at installation allows you to create a user with an & and it is stored in the db with an &
However that user cannot log in

So for me the error is in the installer and it not using the same filtering as the rest of joomla

In fact looking closer the installer uses no filtering at all

The problem is that users are validated in the installer with JOOMLA/media/system/js/fields/validate.min.js
const regex = new RegExp('[<|>|"|\'|%|;|(|)|&]', 'i');
But in the admin they are validated with a completely different regex

It looks like the email is validated differently as well

The problem is that users are validated in the installer with JOOMLA/media/system/js/fields/validate.min.js
const regex = new RegExp('[<|>|"|'|%|;|(|)|&]', 'i');
But in the admin they are validated with a completely different regex

Just use the HTML5 pattern in the XML and use the same regex. That should fix the inconsistency (assuming that the pattern is working correctly otherwise blame me and I'll get it fixed)

I can do that (and agree) but then we have multiple unused regex in multiple places

Remember I wanted to do #18995

Plus the error message from an html5 pattern isn't very good as it doesnt tell you why it fails

I assume though that it is automatically translated according to the browser language

Just use the HTML5 pattern in the XML and use the same regex

Plus the error message from an html5 pattern isn't very good as it doesnt tell you why it fails

text field layout now has ...

$attributes = array(
	...
	strlen($hint) ? 'placeholder="' . htmlspecialchars($hint, ENT_COMPAT, 'UTF-8') . '"' : '',
	...
	!empty($pattern) ? 'pattern="' . $pattern . '"' : '',
);
?>

We could try adding support 1 new attribute to the XML files
error_hint="..."

$attributes = array(
	...
	strlen($hint) ? 'placeholder="' . htmlspecialchars($hint, ENT_COMPAT, 'UTF-8') . '"' : '',
	...
	!empty($pattern) ? 'pattern="' . $pattern . '"' : '',
	!empty($error_hint) ? 'oninvalid="setCustomValidity(\'' . htmlspecialchars($error_hint, ENT_QUOTES, 'UTF-8') . '\');" ' : '',
	!empty($error_hint) ? 'oninput="setCustomValidity(\'\');" ' : '',
);
?>

I see a new attribute for XML definition of text field already exists in J4 and it is called ?
'validationtext'

thus the above can be used ?

Thus i suggest adding attributes
pattern
validationtext

to the password field like they exist in the text field

[EDIT]
and to any other fields that can possibly use them (if there are any other such fields)

@ggppdk I've already implemented the validationtext because I thought it will be handy. I guess I should have implemented one field as a showcase as it's now pretty hard to figure out without reading the code. Ooops sorry...

@dgrammatiko give me an example and I will see what I can do. This is especially important for accessibility as it will allow us to have inline error messages instead of having them out of context in an alert

@brianteeman the xml should be like (you'll need to use the right regex though):

and then it should just work:

the regex is no problem ;)

as for the validationtext - does it support Jtext?

@brianteeman that part was never implemented. in libraries/src/Form/FormField.php line 1002 change it to 'validationtext' => Text::_($this->validationtext),. That should be enough to introduce the translations

Ok well I can see what I am doing tomorrow

Fixed with PR #23918 in J3.

@Quy that might not fix the issue here as the installer for j4 is almost completely different code

imho #23918 is not enough we lack the client side validation
but in the meantime test the server side one ? #24024

@alikon @brianteeman the front end part was already fixed in
#21584 but then that PR was closed. FWIW my intension when I did patch the validation.js to deal with the pattern attribute was to move to HTML5 validation and also have one regex per field (php or js). Obviously converting all the forms is kinda big task but honestly I hope someone will do it for J4. Brian already showcased what needs to be done, it's not hard but it's a big task

Fixed with #23918 that has ported to J4.