Closed luckyrat closed 3 years ago
When this option is enabled these things will no longer autofill after initial page load unless no entry was auto-filled when the page first loaded:
Storing all the relevant information to allow us to automatically determine with certainty that these situations have arisen will be a huge undertaking and I suspect the need to refresh the page or manually select the preferred entry from time to time is a minimal drawback compared to the benefits of this new behaviour so I don't currently plan to develop exceptions to the new behaviour. If many people have to disable the new option, we can at least keep it around for the long-term, or see if anyone is willing to make the necessary changes to be able to track when the value in a form field is from an earlier matched entry auto-fill operation.
We already block autofill if a user has modified the contents of a form field but we do still see occasional reports of data being overridden accidentally.
In situations where we incorrectly think that we should autofill a form, this new default-on option will mitigate the impact.
Interestingly, the incidence of this problem has increased in the past few weeks as a result of fixing the bug that prevented autofill of forms containing a form field with a name or id attribute with a value
name
. That's becausename
is also on the include list so that pages with just a username field (no passwords) can be correctly filled.Spending time on improving multi-page sign-in support is the right way to solve the underlying challenge but that's a huge task so this will help in the short term.
I expect the negative impact of enabling this by default for all users will be minimal but it's hard to predict so we will await feedback and once the new form field and multi-page form support has been rolled out we can determine whether or not to keep the option, and if so, what to default it to.