Site configuration form - move email field below password field to avoid confusing password managers

D7 should not be held up by this. Setting to normal. Re-roll.

This seems to be a pretty minor bug - when I tried it, the Firefox password manager still functioned correctly, just that of the two things it could have chosen to remember (email address or username), it remembered the one that I'm more likely to know on my own, that's all. Also, if I'm not mistaken, this only affects people who reinstall the same exact Drupal site more than once, right?

I don't know if it makes sense to rearrange the form or not, but I think we ought to have more reasons than password managers if we are going to do it :)

Also, the one bug I did see with the password manager when I did this is that it tried to reuse the same credentials on the database screen as I had entered on the site information screen (even though those two have nothing to do with each other). I guess this is because both are displayed at the same URL.

Perhaps it's the case that they shouldn't be at the exact same URL, although I'm not immediately sure of a non-hackish way to fix that...

You really shouldn't be using a password manager on install.php.

I interpret ff1's reason for closing this issue as password managers remembering credentials per url. I agree that it wouldn't make a lot of sense to remember the password for http://example.com/install.php. However, at least Firefox learns the credentials for the entire site, so whenever a page on http://example.com/ asks for them, it will supply them (as David_Rothstein noticed).

I don't see why "You really shouldn't be using a password manager on install.php" if it can work, and I don't see why we would not want to make it work. Think of a reviewer installing Drupal for the first time. He'll immediately notice that Drupal fails to cooperate with his browser's password manager. Why would we want to expose D7 to such a cheap shot?

It's probably too late for the release, but this still deserves to be fixed.

#4: 382124-4.patch queued for re-testing.

The credentials you supply on install.php are for user 1. This user is in a role that has unlimited permissions on a drupal site and it is not recommended to use this role regularly. So I'll re-phrase my last post: I can't see any reason why someone would want to use a password manager for install.php. If there are valid reasons, then great, we should get this in, but it needs further discussion first.

Drupal should not nanny the admin. Especially not by causing failures to cooperate with other common software. This is a bug, NOT a feature.

I run install.php far more often for a local test installation (on my local computer) than for setting up a public site. And I'm grown up — I want to make my own choices.

Do you really think that Drupal's failure to pass the proper credentials to the password manager at the first occasion will keep anyone from saving the right ones at the second occasion? The only thing that you're accomplishing is to create a bad impression early on.

Sorry Salvis. I wasn't disagreeing with you. I was merely clarifying my hastily posted comment in #8.

It is obviously a bug that you would like fixed and there appears to be a simple fix posted in #4. So are there any good reasons NOT to swap the order?

Just for info, this is the firefox bug report to show that this is a common problem that can be fixed by this patch: https://bugzilla.mozilla.org/show_bug.cgi?id=443800

I'm not sure the above patch actually does anything? (It moves the code around, but doesn't adjust the weights of the form elements so I don't see how it can affect things.) Also, at this stage of Drupal 7, making changes to the user interface has a pretty high bar so it seems tough to imagine it getting in until Drupal 8...

Before committing this, we'd need to think about whether the new ordering is more convenient for users also. The form needs to be optimized for humans too, not just for browser quirks :)

You're right. Without adjusting the weights, the patch doesn't do anything.

What puzzles me is that this works correctly on the user/UID/edit page. I've compared the code in install.core.inc and user.module. On the user/UID/edit page we have
name
current_pass
mail
pass

It's the same sequence, but there's an additional password field between name and mail, and adding the current_pass field on the install form allows Firefox to detect the user name correctly (and it also picks the right password)! Now that is a quirk! This means it's pure luck that it works on the user/UID/edit page.

Obviously, we can't add current_pass to the install form; I've tried adding a dummy hidden field, but this hasn't helped. I've also tried removing '#tree', without success. Maybe there's some other trick to get this to work?

In the meantime here's the patch from #4 with the correct weights.

I have created patch for this that is working fine and applied successfully

I am making this issue a child of #3251513: [meta] Update the user-edit pages in order to group it with other issues that aim to improve the user-edit form.

It's 2021, what password managers are still having this problem?

@cburschka this issue is not about the Edit Profile page, but about the Site configuration form (install.php).

The manual testing is still needed to check if this is still relevant.

Patch #15 does not apply anymore and reroll is needed. The new patch is #17 is not working for me, because it only moves the form element in the code, but is not adjusting the weights (see also #14). This patch was not needed at all, as the only thing needed was a reroll, not a new patch with a different approach.

Therefore switching this to Needs Work.