TYPO3 Core

I also noticed that.
I think the reason might be, that I entered the password-data in my browser to fill out the fields automatically.
Then, when I open the module, the first password-field is filled, but the second is not.

Is that also the reason for you?

Good point!

Clearing the password field manually does indeed solve the problem.

Maybe renaming the password field in module "User settings" could solve this issue permanently?

BTW: Why does the "Create enable install tool" button to the same HTML-form that holds the user data?

Isn't saving / resetting user data a complete different task?

i don't see a problem with this message. The autofill is done by browser, not by code. When you don't use the autofill (eg IE) the message doesn't appear.

Cleaning from code isn't possible because browser fills the field after render.

The problem is, that the enable-button actually saves the content of the form!
But that is what the save-button should do!
The enable-button should NOT save anything. This is really confusing!

In my eyes the problem is that two actions are commited when trying to create the ENABLE_INSTALL_TOOL file:
1. ENABLE_INSTALL_TOOL (this is expected)
2. All user data is submitted and saved (which is NOT expected)

A solution might be to separate these actions.

Probably the button to create the ENABLE_INSTALL_TOOL file has to be moved out of the user data HTML form.

The button was moved to this tab newly. But if I remember correctly noone considered this problem... The idea of moving it back sounds good.

I still don't like the button to trigger to distinct actions but one simple solution not to break the current logic would be to disable autocomplete for the password field.

Simply add autocomplete="off" to the corresponding input and we're done!

This is compliant to XHTML 1.0 transitional, see http://aktuell.de.selfhtml.org/artikel/html/autocomplete/

#21271 is solved, but the problem still remains:

The button to create the enable file saves the contents of the tabs. This should not be the case.
And - if possible - it also should not reset changed values which are still unsaved.

Can you create a patch fixing this wrong behaviour?

This was fixed with TYPO3 4.3-RC1