Identical switch case block in core/modules/user/user.js

I see what you are saying, @Patil_kunal27. And you are right, but if we look at the rest of the code, I think that the mistake here is that there is a 'case 4' in the switch at all.

The count of weaknesses (applied, after this to a strength factor based on the password length) is based on whether or not the password is missing any of four factors: lowercase (a-z), uppercase (A-Z), numbers (0-9), punctuation (any other character, at least by the definition this code is using). For each of these factors, the count of "weaknesses" is incremented (weaknesses is a variable initialized to 0 before this block).

So it appears that the mistake is really that we have a 'case 4' at all, since it should not be possible to enter a string of characters that don't have any of the four "character types". Even odd non-ASCII glyphs would fall into this code's definition of "punctuation", so a string containing all of the four "weaknesses" defined by the password strength-checking algorithm shouldn't be possible, as far as I can tell.

The changes this patch implies are so trivial (they don't affect the strength calculation at all), so I think this could still be applied to the current 8.3.x version of core without need for waiting till 8.4.x. That said, since it also makes no change to the outcome of the calculation, it also could wait. ;-)

I've attached a patch which simply removes the 'case 4' block from that switch statement. (And since I've done that, I guess I can't do what I was first hoping to do: mark this as RTBC... someone else will have to do that.)

Typo making the patch and ended up making an empty file. (Oops.) This is the patch I meant to upload.

There really should be some way to immediately delete a mistakenly-uploaded .patch file (and remove it from the testing queue), just as we can edit our comments. ;-)

Why does #7 refer to "the last submitted patch", when it was really "the patch before last"?

(And why does the system accept an empty patch file and trigger a test run? I cannot imagine that happens very often, but it should just be able to reject such a patch on attempted upload without blindly running all the tests, shouldn't it?)

I understand the point, but this issue is not a bug.

Bumping to 9.3.x

All right! Moving to RTBC.

Drupal.evaluatePasswordStrength() does get called with passwords only consisting of spaces. They will then be trimmed to a 0 length string and fail all the text. In this instance weaknesses will equal 4 so I think we should go back to #2.

A new patch...

RTBC!

Committed 5b5988c8fa and pushed to 9.3.x. Thanks!