User Agent Style shows as being overridden, but when the page renders, it's not

Question

I am trying to hide the autofill style for a password input field that comes in via the user-agent-styles.

When inspecting the element, the computed styles show that the color coming from the user-agent-style is being overridden and #fff is being applied, but the actual computed style is still the one coming from the user-agent.

Any idea on how to get rid of this?

Here is the CSS I am using to try and override it:

.password {
    border-right: none;
    background-color: #fff !important;
}
#MainContent_txtPassword:-webkit-autofill, input:-internal-autofill- 
previewed, input:-internal-autofill-selected, textarea:-internal-autofill- 
previewed, textarea:-internal-autofill-selected, select:-internal-autofill- 
previewed, select:-internal-autofill-selected {
   background-color: white !important;
}

Answer 1

I found an answer that works for me! See https://webagility.com/posts/the-ultimate-list-of-hacks-for-chromes-forced-yellow-background-on-autocompleted-inputs

I had initially come across https://css-tricks.com/snippets/css/change-autocomplete-styles-webkit-browsers/ but that only works for opaque backgrounds, and not transparent ones. The webagility article includes a nice hack for transparent backgrounds too.

To summarise both the articles, the solution I applied is:

input:-webkit-autofill,
input:-webkit-autofill:hover,
input:-webkit-autofill:focus,
textarea:-webkit-autofill,
textarea:-webkit-autofill:hover,
textarea:-webkit-autofill:focus,
select:-webkit-autofill,
select:-webkit-autofill:hover,
select:-webkit-autofill:focus {
  -webkit-transition-delay: 99999s;
}

The reason this works is because chrome applies autocomplete styles via a css transition. If you delay all transitions on that input, the styles will never be applied.

Answer 2

This behaviour is seen in Chrome only (it is not in Firefox, I didn't test Edge or others). Chrome applies a pale yellow background (#E8F0FE) and black text to all autofilled inputs. This user agent style for autofilled text has hard-coded priority in Chrome's rendering since Chrome version 74. This behaviour is intended by the Chrome developers.

In Chrome, these hard-coded styles will override anything you can set yourself in the document or via Javascript. In the original question, Style Inspector shows the OP's background-color: white !important style as having precedence over the user agent style input:-internal-autofill-selected. Style Inspector is wrong to show that: it looks like it does not know that the user agent style for autofilled text has hard-coded priority.

I replicated the OP's issue in a (codepen). Note that I even tried to update the input:-internal-autofill-selected user-agent style in the document's own CSS, with the !important suffix. Even with that in the CSS, Chrome still uses the original, hard-coded user-agent style. This codepen also shows you that none of the following methods will be effective to override the user agent style in Chrome.

1. use CSS with greater specificity
2. add style to the element in HTML
3. use an event in Javascript to change the element's style properties (for example backgroundColor) after data is entered

This has been reported to Chrome as a bug. The developers' response is WontFix, citing a security concern. Chrome devs don't say what the security concern is, but I guess it is that a malicious site could create HTML with hidden input boxes (no border, and background and foreground colours matching the page background) and gather some auto-filled data without the user's knowledge.

This "WontFix" attitude is not a great solution. It annoys designers who want to control the appearance of input boxes. The OP wants a pure white background and Chrome changes it to #E8F0FE which is maybe not a big deal, but it's way worse for designers who want to use a dark background. How hard would it be for Chrome to check programmatically that the page has styled the input box with high enough contrast to be visible to the user? Chrome has also not fully solved the security concern, because a malicious site can hide an input box in some other way: it could be outside the visible screen area, or covered by a different page element.