[Webkit-unassigned] [Bug 245254] New: Safari 16 treats <input type="email" autocomplete="email"> as login by default

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Sep 15 16:35:51 PDT 2022


https://bugs.webkit.org/show_bug.cgi?id=245254

            Bug ID: 245254
           Summary: Safari 16 treats <input type="email"
                    autocomplete="email"> as login by default
           Product: WebKit
           Version: Safari Technology Preview
          Hardware: All
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Forms
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: aleksey.gladysh at gmail.com
                CC: cdumez at apple.com, wenson_hsieh at apple.com

Created attachment 462372

  --> https://bugs.webkit.org/attachment.cgi?id=462372&action=review

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220915/4ffff8cd/attachment.htm>


More information about the webkit-unassigned mailing list