Password strength indicator display broken in install process

It looks as though there was no CSS at all for the password strength. In comparing the install form to the user edit form, user.css from core user.module was adding in the required styles for the password strength checking.

I'm not sure if this file was ever included in the install process, but adding it back to the form made the password strength checking work fine for me.

In install.core.inc, function _install_configure_form, I added the following

$form['#attached']['css'] = array(drupal_get_path('module', 'user') . '/user.css');

I'd supply a patch but I'm not sure if the css was ever included from user.css, where it may have been, or why it may have been removed.

Adding in the entire contents of user.css had no detrimental effects on the rest of the page.

Noticed this too... Seems at least normal priority (if not major); that floating word looks very ugly out there.

I think attaching the CSS is probably the right way to go but I wonder if we can track down what caused this regression in the first place. Maybe there already exists code somewhere that is still trying to add that CSS but failing for some reason.

I recently did a git bisect, if someone wants to do that to find out which commit broke this. I was not that bad actually.. just a lot of install, test, wipe, install test... etc.

I followed the binary search section of: http://git-scm.com/book/en/Git-Tools-Debugging-with-Git

related: #1811240: Improve "password matches" and "password strength" accessibility

I'm pretty sure it broke with this commit:
http://drupalcode.org/project/drupal.git/commit/2bd155b1069fc631c1e1b0d0...

In that commit:

Removed from user.info:
stylesheets[all][] = user.css

Replaced with in user.module:

/**
 * Implements hook_page_build().
 */
function user_page_build(&$page) {
  $path = drupal_get_path('module', 'user');
  $page['#attached']['css'][$path . '/user.css'] = array('every_page' => TRUE);
}

This is equivalent for normal pages, but hook_page_build is not called for installation pages, because those are run through the maintenance page theme. Given this, it seems like using the form attachment is reasonable, but the corresponding user.js file is actually loaded onto the installation page from user_library_info(). user.js is almost entirely about the password widget, so if that's being loaded through user_library_info(), I think user.css should be, too. I've tested it, and it fixes the problem. (as does the form attachment method)

Attached is a patch to add user.css to user_library_info().

Does what it says it should. :)

Hooray! :) Thanks for tracking this down!

Committed and pushed to 8.x.