Claro's password element handling invalid fails in some circumstances

I don't know why we do not use strict comparison for in_array checks using claro_preprocess_form_element__password() (anyone?), but after reviewing these 2 small code additions (2x , TRUE added), no code removals, and after testing local on latest 9.3.x dev Drupal core and on Tugboat with Claro set as default theme and using the project code of the project the OT worked on while detecting this behaviour, I can confirm that the patch provides the intended strict comparsion without breaking anything and the Drupal installation operates as expected without any flaws.

One last question, is the previous implementation the default, or does "Seven" admin theme behave different here? RTBC from me. But I would tend to say it needs one more review.

Ok. So there is no "similar" issue possible in Seven etc. GTK...

To quote https://www.php.net/manual/de/function.in-array.php#106319:

Loose checking returns some crazy, counter-intuitive results when used with certain arrays. It is completely correct behaviour, due to PHP's leniency on variable types, but in "real-life" is almost useless. The solution is to use the strict checking option.

So - I would like to RTBC to speed things up, but I'll ping a maintainer to make sure it gets another eye on it.

Committed 4cbbdb2 and pushed to 9.4.x. Thanks!

This doesn't need test coverage as doing so would effectively be testing PHP.
Running this PHP snippet demonstrates how in_array() can lead to unexpected positives when strict checking isn't enabled.

$variables = [];
$variables['element']['#array_parents'] = [
  'whatever' => true,
];

if(in_array('pass1', $variables['element']['#array_parents'], TRUE)) {
    echo 'strict true';
} else {
    echo 'strict false';
}
echo "\n";
if(in_array('pass1', $variables['element']['#array_parents'])) {
    echo 'relaxed true';
} else {
    echo 'relaxed false';
}

Leaving at RTBC and switching version to 9.3.x for potential backport after the code freeze.

I think this issue is good for backport because it seems low risk.

+1 backporting this.

+1 backporting this.

Went ahead with the backport since this seems like a low-risk change and Claro is experimental.