Created attachment 462372 [details] Our newsletter sign up form with login autocomplete icon in it on page load Safari 16 on both iOS and macOS treats any <input type="email" autocomplete="email"> element in a context it doesn't recognize as a login field. Generally, the correct autocomplete value for that would be "username" but I can see how some developers could mistakenly use "email" in a sign in form when the login is also an email address. The context detection seems to work on contact and sign up forms, but the problem is that when there is little to no context, Safari assumes it is a login field, which breaks simple forms like newsletter sign up forms, which typically only have the email field and no other fields to provide context. Once Safari assumes a field is a login field, there is no way to override it as the autocomplete attribute is intended to. I first noticed this issue with a website I work on for work and our newsletter sign up form in the hero. Both iOS and macOS Safari 16 treat it as a login field, but macOS Safari goes a step further by autofocusing it when it is above the fold even though there is no autofocus attribute or autofocusing JS on the page. I then looked for a similar pattern and found an example on Shopify.com. The email field they have on the home page is not meant to be a login as it clearly doesn't log you in when you autofill your email. I'll attach screenshots of our site and Shopify's home page plus the next step once you fill in the email and it doesn't log you in. I don't think an email field should be assumed to be a login field and attributes meant to control that behavior should actually work.
Created attachment 462373 [details] Shopify's home page
Created attachment 462374 [details] Shopify's page once you enter the email; it doesn't log you in
Thank you for the report! This functionality is mostly implemented in Safari, not in WebKit. Could you please report this via https://feedbackassistant.apple.com for Apple engineers to take a look? When you report it there, please clarify whether this is a new issue in Safari 16 that doesn't reproduce in earlier versions.