I believe this is intentional behavior of password autofill - the page is not allowed to read the password until the user interacts with the page for security reasons (so it's not actually autofilled yet, the UI is just an indication that the password will be autofilled if the user clicks).  Some discussion at https://stackoverflow.com/questions/35049555/chrome-autofill-autocomplete-no-value-for-password

To Autofill in case they have more context.  That others browsers apparently don't do this with their autofill behavior is certainly a source of confusion.  Ideally browsers would agree on how to behave here.

I agree with the security reason argument. However the UI indicates that the input is filled so we should have (css) :valid = true & (js) valueMissing=false even if the actual value is not available. I'm using the :valid css property to style my input, if it looks like it's filled I should be able to style it accordingly :)

Also, I guess it means that JavaScript might be able to use the computed CSS to determine the password? So perhaps not much of a defense.

Shall we consider this as feature request? Please confirm...

I don't understand the security argument. What is the threat vector here? It's not like you could snoop a different site's pw.

Related to  issue 669724 .

 Issue 762361  has been merged into this issue.

I don't think this is a feature request; all other modern browsers do not have this bug.

Chrome seems to be the only browser that views this as a security issue and it's unclear what the attack vector here is. Regardless, it seems like it should be possible to support :valid before interaction without leaking the password anyway, right?

over to battre@ for passwords triage

This an extra barrier in case two sites have XSS, where one is used to open the site with the stored password and the other one is used to extract the password. I don't think that we currently have plans to change the behavior. We may consider a different UI by which passwords are filled that would address this as well, but with the current UX I don't expect a change.

Could you clarify how the CSS :valid psuedo-selector and/or the JS Validation API (e.g. input.valid) could be used for an XSS attack? At the very least, it seems the CSS selector in particular would be safe to allow.

Currently the password is not exposed to the renderer process until you have a user gesture. +vabr to keep me honest

So are you saying it's impossible to check if an input field is CSS :valid without exposing the entire value to JS (and thus a potential XSS attack)?

Please forgive my lack of knowledge of Chromium's internals if I'm mistaken.

Chrome is split into a browser process and multiple renderer processes. The renderer is in charge of doing CSS evaluation and does not see the credential until the user makes a user gesture.

Also, I can imagine that CSS validation could be used to snoop the password: Just observe the valid state as you cycle through different regexp patterns (a*, b*, ..., aa*, ...).

PasswordAutofillAgent::FillUserNameAndPassword actually calls SetSuggestedValue before the first user gesture occurs, so the renderer does have the password from the beginning and could in theory infer the CSS :valid from the suggested value in the absence of the real value. I have not thought about caveats of that, though, we'd best talk to someone knowledgeable in blink forms for that.