Uncaught TypeError: Object #<Object> has no method 'drupalSetSummary'

summary_error.patch queued for re-testing.

I am also experiencing the same cursor jumping frantically from the second password box to the first one. This happens without caching and although the patch stopped the error it did not resolve the issue of the cursor jumping to the first password box.

not experiencing the cursors issue (did experience it before, but I believe that got patched by another patch). I do however have this error. So maybe the cursor issue and this error are unrelated.

Based on some other posts about JS messages about drupalSetSummary thought maybe I had to increase PHP's max_input_vars and max_input_nesting, but that didn't help either. I think I have ruled that out as a possible cause. I also tested with and without JS aggregation.

I noticed that drupalSetSummary is defined by /misc/form.js but that JS file is not loaded on the /user page. So naturally it can't find this function. I added a JS include to my theme's html.tpl.php, but then /misc/form.js complained that jQuery was not defined, even though it is ... I am using it throughout the site and the /user page does include the jQuery JS file too.

Yes, the cursor issue was resolved for me with the dev branch.

Is there a reliable way to reproduce the error? Where do you see it?

I am unable to reproduce it. From a fresh Drupal installation:
1. Created user 'foo'.
2. Created roles 'bar' and 'baz'.
3. Assigned user 'foo' to role 'bar'.
4. Created password policy, applied to role 'baz'.
5. Logged in as user 'foo'.
6. Changed password via 'My account' page without any such error occurring.

Need information per previous comment.

A month has passed with no information on how to reproduce this. Please re-open if you still have this issue.

I have a same problem.
My patch works fine for me

spheresh: Thanks for the patch. How can the problem be reproduced so I can try it out? Also, which browser are you using?

Hi, AohRveTPV.

I use Chrome, but is sure that it is not dependent on the browser version.
I display the user registration form using the panel, and perhaps the problem lies somewhere deep in the core of Drupal or Ctools.

I do not know the reason why the form.js file is not connected, but in any case, the patch will not be redundant.

What is the panel and how do you put the user registration form there? (Is this functionality provided by the Panels module?)

It would be very helpful if you provided steps of how to reproduce this problem from a fresh Drupal 7 site.

It is not clear to me why including forms.js would be necessary, and whether that will even fully fix the problem. Committing some code that fixes the problem for some users for reasons unknown would be programming by coincidence. A way to reliably re-create this problem is very much needed.

Unfortunately I do not have much time to describe the problem, but I will make a screen, it will be clear to users

so I deduce the registration form, as this is vital for my project

I believe that we need to connect the form.js file, as password_policy.js uses drupalSetSummary function from it.

and module password_policy should care about connecting all libraries.

Thanks, spheresh. I am now able to reproduce the drupalSetSummary() problem. The original bug report also mentions the cursor "jump[ing] frantically from the second password box to the first one". I did not observe any problem with the cursor. Do you observe this cursor behavior?

Steps to reproduce:

1. Install Drupal.
2. Install/enable Password Policy 7.x-2.x-dev.
3. Administration->Configuration->People->Account settings->Require e-mail verification when a visitor creates an account: unchecked
4. Follow "Create new account" link.

In the Firefox Web Console, the following error is observed:
TypeError: $(...).drupalSetSummary is not a function

Patch in #9 seems to be the right solution.

The module was relying on the drupal.form library being incidentally loaded by other elements on the user edit page, etc. to provide drupalSetSummary(). For instance, if there was a collapsible fieldset for timezone selection on the user edit page, drupal.form would be loaded.

Versus #9 I have moved the drupal_add_library() call to what I think it is a more logical place in password_policy_password_element_alter(): adjacent to the attachment of password_policy.js. Hopefully this has no functional effect.

Besides password_policy_password_element_alter(), PasswordPolicy::admin() also loads password_policy.js. However, it does so in vertical tabs, which I think will cause drupal.form to incidentally be loaded. It might be an improvement to explicitly load drupal.form there even though it is not needed.

I wonder if it might be a better approach to define a library for password_policy.js and list drupal.form as a dependency so it is implicitly loaded. password_policy.js does not really provide a library for other modules to use though, so this may not be appropriate.

Seems more consistent to load the library using #attached as with password_policy.js. Please comment if this approach is disadvantageous for some reason.

Looks good, I'll try this patch in my project, soon. Thanks.