7

Steps to reproduce:
<Include steps to reproduce the bug; Did you try using Compatibility mode? If applicable, does Safari behave in the same way?>
Use other passwords
Expected behavior:
<What you expected to happen?>
I thought when I open “other passwords” I will see all the iCloud passwords I saved on my device instead I saw nothing

Orion, OS version; hardware type:
Iphone 12, ios 15.4.1

Image/Video:
<Copy/paste or drag and drop to upload images or videos (up to 20MB)>

  • Vlad replied to this.
    5 days later

    Ksanusii Please state full steps to reproduce the issue and/or a video.

        9 months later

        I have same problem iOS 16.1.1
        Orion 1.2.4 (2) (WebKit 8614.2.9.0.10)
        iPhone 13 Pro

        It appears on a few websites but on most websites I don’t have the iCloud passwords

        Example websites it’s not working at:
        https://auth0.openai.com/u/login/
        https://accounts.google.com/v3/signin/identifier
        https://twitter.com/i/flow/login

        Where it’s working
        https://login.fastspring.com/identity/auth/login
        https://m.facebook.com/

        Just a hunch but it seems to me that it’s WORKING on websites where the passwords have a “list” of websites its attached to in iCloud and the actual website im looking at is NOT the FIRST on the list.

        And when it does NOT WORK then the actual website is FIRST in the domain list.

        How it looks when it’s working vs not working

        List of examples from keychain (with suspected pattern)





        (And yes I can’t count; on one of the photos I wrote 3 to the 4th entry but you got the point)

          Good to see you looking at it Vlad!

          As a side note this button ALWAYS appears in Safari browser (even for website forms that have no saved password).

          Because sometimes the user wants to use a known password just on a different domain he haven’t used it before.

          (E.g I have password saved at auth0.chat.com but now I want to use it on login.chat.com)

            Love the planned flag! Let me know if you need any more input or testing Vlad

              18 days later

              I've done some investigation, and my conclusion as to the root cause of this is:

              • Open any sign-in page
              • If there are both an email/username and password field visible (e.g. on https://m.facebook.com/), tapping on either field does show the iOS-native "🔑 Passwords" button directly above the keyboard, as well as the Orion-native password autofill bar (black bar with blue text/icons) above it.
              • If there is only an email/username field (e.g. https://twitter.com/i/flow/login), and you have to press some sort of "Next" or "Continue" button before entering your password, then tapping on the email/username field does not show the iOS-native "🔑 Passwords" button above the keyboard. Instead it seems to usually show the "suggested words" input accessory. The Orion-native password autofill bar will still show above this.

              The above behavior affects every 3rd-party browser I've tested on iOS, not just Orion. Safari seems to still show a Password input accessory even when they only see a single email/username field. That password input accessory is controlled 100% by the system, which seems to be why Orion, Chrome, Firefox, etc are all suffering the same issue.

              • Vlad replied to this.

                Vlad did some digging and so far I have two paths we can take:

                • Reach out to the WebKit team and file a bug, since this seems like a WebKit iOS bug. If there’s anything we can do within the bounds of implementing the public WebKit framework, maybe they’d know what would fix it. It’s possible it won’t get fixed in the public framework for a while, if ever.
                • We (Orion iOS) can inject a fake password input field, rendered offscreen (it needs to be “visible” to WebKit), and it’s existence seems to trick WebKit into showing the “Passwords” input accessory. I’ve got a proof of concept using JavaScript that seems to work on the sites listed above, but it’s certainly hacky and I don’t know what side effects it could have across the many sites where this would be used.

                I’ll definitely file the bug with the WebKit team. As for the hacky option, let me run my proof of concept through a few dozen login pages to see if it breaks anything, and I’ll share the code with the Orion devs to see if they can spot any issues or suggestions.

                  2 years later
                  No one is typing