entering only "Confirm password" field passes validation and returns success message

Looks good.

This is a stupid bug to have. Let's get some tests for this.

First a quick reroll. We will try to write a test for this at the Paris code sprint today

Now with test

Patch applies fine and fixed the problem
+1

I adjusted the tests a bit and rerolled.

#7: password.patch queued for re-testing.

I'm rerolling

Patch rerolled. I removed the part of the test with the wording criticized in #8 (the part showing that matching passwords do work) because it now seemed to be redundant with existing tests.

Reviewed and testing with drupal 7.x-dev and worked as expected. The patch checks both password fields and if the 'confirm password' field is empty it returns "The specified passwords do not match."

Works when one of the two is null, but exhibits some odd behavior from a usability standpoint when both are null.

Three possibilities:

If "confirm password" is null:

Error Message
----------------
The specified passwords do not match.
Your current password is missing or incorrect; it's required to change the Password.

If "password" is null:
Error Message
----------------
The specified passwords do not match.

Both Null:
Error Message
----------------
The changes have been saved.

>>> This makes sense in a way since one could change the their timezone and would not need to enter their passwords. But oddly, (is this is separate issue?) it returns The changes have been saved. when no changes are made and the form is posted (technically this may be true, but it's a little odd from a usability standpoint).

Committed #12 to CVS HEAD, but we might want to tweak things some more based on #14.

Subscribing

Here is a quick fix for #14 issue based on Jody Lynns patch:

  $pass1 = trim($element['pass1']['#value']); //Get password
  $pass2 = trim($element['pass2']['#value']); //Get confirmation

//Only match if both fields filled:
  if(!empty($pass1 || !empty($pass2)){
     if(strcmp($pass1, $pass2)){
        form_error($element, t((empty($pass1) && !empty($pass2))?'Your new password is missing or incorrect; it\'s required to change the Password.':'The specified passwords do not match.'));        
     }
//Check wether the password is required input: 
  }elseif($element['#required'] && !empty($element_state['input'])) {
     form_error($element, t('Password field is required.'));
  }
 

I'll post patch after finding a good solution for that "The changes have been saved" - message
even if no changes have been...

The solution mentioned in my previous post can be found from this patch.

Needs a reroll because everything moved to core/* in D8.

Oh. This is 7. Never mind.

#12: password.patch queued for re-testing.

To the best of my understanding, the test cases for this issue and for changing password or other user details are complete. I can't think of anything else that should be included except for the case when the message "The changes have been saved" is displayed even when there have been no changes. Any suggestion is welcome.

All the changes suggested in #14 have already been committed(commit no 66d75d16fcc1e531811fb3bcf32a2f4318c01588). And the tests for the same already exist. The only thing that seems to remain is finding a solution for "The changes have been saved" message as mentioned in #14. But that appears more to be a feature request than a bug an this is apparently "impossible" to fix. I therefore suggest to close this issue as it has been open for quite a long without really making much sense.

@rkjha and I talked about this issue in IRC today.

As far as we can tell from looking at this issue and performing manual tests of the user edit form, the only change (at least for D7/D8) that is mentioned in #14 is that when no changes are made to the user profile, the message "The changes have been saved." should not be displayed.

We agreed that #14 seems like more of a feature request, and that it would need to apply on a higher level so that for example updating a node without changing any fields would not say "[node:title] has been updated."

So unless we're both missing something, I think we can close this issue as fixed since the main issue was addressed with the commit in #12 and the response to the request in #14 would likely be "closed (won't fix)" or maybe even "closed (works as designed)".

I can't see any reason to keep this open now, no.
I'll bump it to 'as designed' as this original issue has been fixed enough now.