It doesn't matter what the password is protecting on any particular site. Password reuse is common enough -- who knows what else the user is protecting with that password.
This is actually a good example. The password clearly isn't protecting anything. It's a tutorial on how to make a password field! Nobody is going to put a valuable password in there.
> who knows what else the user is protecting with that password
How does it even matter when the password field is never even read? There are better alternatives. Chrome could just give a security error when the password is actually accessed. Or alternatively it could prevent the page from storing any data locally or sending any data to any server if the password field is non-empty. Just because a password field exists that doesn't mean the page is insecure.
If you have a password in a form that gets submitted to the server and you're not using TLS, then anybody between your user and the server (which is a lot of people these days) can read that password and the associated username (and all data ever sent) in plain text. There's zero confidentiality.
If you're putting a password field on a page where nothing is ever sent over the wire, I'm not sure what value that password field is really adding, anyway. Might as well swap it for an input and, voila, your users won't have any warnings.
> If you're putting a password field on a page where nothing is ever sent over the wire, I'm not sure what value that password field is really adding, anyway.
You don't think it was adding anything in the example page I just linked you to?
Since the page is loaded as plain text, it can also be altered by anyone with network access between the server and the user. Javascript can be very trivially injected that simply sends each keydown event to the server, giving away the user's "hidden" password.
So even if the code you wrote doesn't ever send the password input to the server, that doesn't mean code hasn't been injected by some third party by the time it gets to your customer/user.
