Email is asked before user name in SiteConfigureForm

1: email-is-ask-before-username-in-site-configuration-2294313-1.patch queued for re-testing.

Pretty sure there is JavaScript to auto set username based on email?

Corrected order of name and mail field order in test case.

@Dominique, Good Job!

PS : someone knows how to run tests in local WAMP env ? Because of #2239969 I'm not able to run unit tests in the Test module UI.

Enable "Testing" module and then you can run local test through /admin/config/development/testing.

Tagging for sprint.

It seems http://simplytest.me is ideal for testing an issue like this.

I'm working on this issue to test the patch.

The latest patch #10 applied fine on the files in core.
It works on the screen install, the two forms elements are in correct order now.

But there is an error of the coding standard https://www.drupal.org/coding-standards#indenting,
the indentation of 2 spaces is wrong with the new admin_account account mail form element :

+++ b/core/lib/Drupal/Core/Installer/Form/SiteConfigureForm.php
@@ -160,6 +155,11 @@ public function buildForm(array $form, array &$form_state) {
+    $form['admin_account']['account']['mail'] = array(
+        '#type' => 'email',
+        '#title' => $this->t('Email address'),
+        '#required' => TRUE,
+    );

Incorrect indentation (4 spaces instead of 2 spaces) coding standards

I've created a new version of the patch with the correct indentation.
Please review.

I manually tried to apply the patch with git apply and it wouldn't work for me. Applying it with patch -p1 worked.

Here are before and after screenshots.

Before:

After:

I have re-rolled the patch to see if it applies this time.

#19 applies cleanly.

I can confirm #19 is fine for me too.

So it looks like this was changed explicitly in #2191785: Password managers are identifying/storing wrong username field when creating a user account. So if we're going to do this, we either need an alternate fix for that issue, or we need to verify that it doesn't recur with the fields switched back to the way they were.

marcus7777 suggested possibly doing this via CSS ordering instead of source ordering, which may solve the problem!

Also DIVS. SO MANY DIVS. :P

Ordering via CSS? I don't think this is a good solution :/

What about we rearrange the fiends like this:

Username:
Pasword:
Email:

That would still allow the autofill to work and would make more sense..?

Having had a few moments to think about this; yes, we do need to make autocomplete work but also we need to help the user understand that the identifier for the Site Maintenance Account is the username, not the email address. It has to somehow come first.

I'll have an experiment now to see if Ieva's suggestion at #27 works on a few browsers.

Okay, In the order Username, Password, Email, we do get browsers to autocomplete the forms...

Site Configuration Form:

Logged out admin user logging back in with autocomplete:

All I need to do now is think about where is the most appropriate place to make the patch; here or in the original location? Webchick?

Here is a patch that goes for the Username, Password, Email ordering proposed at #27...

Ah that's better! Sorry about the multiple test runs - I eventually learned there was testbot issued last night.

+++ b/core/lib/Drupal/Core/Installer/Form/SiteConfigureForm.php
@@ -166,7 +160,13 @@ public function buildForm(array $form, FormStateInterface $form_state) {
+    ¶

Could you please remove that whitespaces? :)

Just removed extra space and rerolled #32 patch.

It is a simple enough patch. I'm updating the summary, as the username/password are rightly (IMO) being kept together.

I think it would be good to get some formal UX input though as this is being done for improved UX.

I like this solution

I like this solution, it makes sense. Patch #41 works and is tidy

Awesome! This totally fixes the problem, and does it without having to update tests, so we're good to go. Thanks for sticking with this, folks. So sorry it couldn't be committed live, but OTOH it was a good lesson for everyone in what core committers actually do. :)

Committed and pushed to 8.x. YEAH!