Hello

Even with hashed form-element-names the browser filled out the repeat-email-field. …

Yes, because the names are not the indicators: https://stackoverflow.com/questions/10738090/why-firefox-autocomplete-even-with-different-input-name.

Thank you for the linked explanation. Following quotes from there.

"If form contains more than 3 password fields, the autofill function ignores that form."

Not our case. Would be a really dirty workaround but I do not like it.

"After 1 to 3 password fields are found, the browser looks for login field. The browser does a backward search starting from first password field and assumes that the login field is the first found field of the type text or email or url or tel or number."

That seems to be the breaking point of our registration form. The field above the two password fields is the field #repeat_email. Also it is the field, that gets filled with a user name I often use and so it prevents me to registrate a new user (normally for testing purposes).

Both, the workaround with the hidden fields between the username and the password fields as a honeypot for Firefox as well as the disabled input (<input type="text" disabled="disabled" style="display:none">) between the username and the password fields that stops Firefox from searching (if I understood it correct) are more or less dirty tricks. Setting the type of our spam protection honeypot fields to a value different from email, url, tel or number is no solution because the default template generates a XHTML-1.0-document, where these types are unknown and invalid. Even when we would use a HTML-5-based theme per default, Firefox searches for every textual input type with exception of password and search (and number as non-text-type).

For testing: Can you change the order of the text fields?

I will fiddle with the field order later today. Today is a World-Cup-free-day so I'll have free time.

Tschö, Auge