Changing PasswordField to not send the string passed to setValue to the browser is an interesting idea, though I suspect the actual benefit is quite small. The reason for this is that in typical cases, PasswordField is used for transmitting password from the user and to the server (e.g. login or changing their password) and not in the opposite direction.

I would even claim that an application that has an actual value to pass to setValue() is typically doing something wrong since that means that they're actually storing the user's password (or a decryptable representation) instead of only storying a properly salted hash of the original password.

I think your observation is correct. The behavior I propose could also be achieved manually today by implementing a getter/setter combination which does not reveal the password but uses a place holder value instead.

However, your second claim applies in my opinion only to applications that do not need the real password. Our application requires the actual password for authentication against SMTP servers or database servers. The PasswordField is used in the administrative interface for editing these connections.

We are also affected by this issue and as a result have removed all PasswordFields from the application.
Every user can intercept the password with the browser debugger (e.g. pressing "F12") as long as the PasswordField is displayed on the screen.

Good point about storing passwords for other purposes than end-users' login details. This is indeed something that could be considered, although I'm afraid it might not be on the top of our own priority lists.

Should be quite easily implemented with a separate server-side field for the real value and then storing a random bogus value in the shared state, although you might then also have to override some logic inherited from AbstractTextField. In addition to this, it would also good to have a two-state configuration mode to let users opt in or out from this behavior since it might affect integration with e.g. TestBench or some extensions.

Might be also implemented very generic way with some HasValue wrapper, similar to V8 recent addition
#10643. Might be useful to store SSH keys etc. with TextArea or other controls.

In this case it should be WriteOnlyHasValue, indeed.

Hello there!

We are sorry that this issue hasn't progressed lately. We are prioritizing issues by severity and the number of customers we expect are experiencing this and haven't gotten around to fix this issue yet.

There are a couple of things you could help to get things rolling on this issue (this is an automated message, so expect that some of these are already in use):

• Check if the issue is still valid for the latest version. There are dozens of duplicates in our issue tracker, so it is possible that the issue is already tackled. If it appears to be fixed, close the issue, otherwise report to the issue that it is still valid.
• Provide more details how to reproduce the issue.
• Explain why it is important to get this issue fixed and politely draw others attention to it e.g. via the forum or social media.
• Add a reduced test case about the issue, so it is easier for somebody to start working on a solution.
• Try fixing the issue yourself and create a pull request that contains the test case and/or a fix for it. Handling the pull requests is the top priority for the core team.
• If the issue is clearly a bug, use the Warranty in your Vaadin subscription to raise its priority.

Thanks again for your contributions! Even though we haven't been able to get this issue fixed, we hope you to report your findings and enhancement ideas in the future too!

Please don't stale ... I think other people might still be affected using the PasswordField for display purposes.