Braintree-web: Focus with keyboard tab is not working as expected in Safari, it needs double tab to focus next input

[sedatbasar]

General information

• SDK version: v3
• Environment: https://developers.braintreepayments.com/guides/hosted-fields/overview/javascript/v3
• Browser and OS MacOS 10.15.3 Safari 13.0.5

Issue description

Issue exist on https://developers.braintreepayments.com/guides/hosted-fields/overview/javascript/v3 too. Open the link in safari, and input fields needs double tab to focus. This is working well once u go through all field for one time with keyboard tab or click with mouse. But in first try, it is not working as expected.

[crookedneighbor]

I'm a little confused. Can you clarify whether you're seeing this on desktop or a mobile device? You posted Mac OS 10.15.3 Safari 13.0.5, but keep mentioning needing to tap.

I'm not able to reproduce by clicking on desktop safari, or tapping in mobile safari.

[sedatbasar]

Sorry i updated it to be "tab". I see this on desktop on using keyboard tab. It works well with click..

[crookedneighbor]

That makes a lot more sense.

That's because those codepens are themselves another iframe. We have handling for focussing automatically into the inputs when our iframes are tabbed into, but the codepen iframe does not.

If you try to tab in a non-iframed integration, it'll work just fine.

Going to close this now, but if you are still having issues tabbing into the inputs in a normal integration, feel free to post here.

[sedatbasar]

I dont think it is because of codepan iframes and in my env i dont have iframe and i still have the issue.
And btw https://developers.braintreepayments.com/guides/hosted-fields/overview/javascript/v3 is working well on chrome. and also as i said it works well if u go through all inputs once, after this it doesnt require double tab.

[crookedneighbor]

You're right, when I went to verify, I accidentally opened it in Chrome to tab through instead of Safari 🙃

I can verify the buggy behavior now. We'll take a look, thanks for the report.

[telegraham]

I'm seeing this too — SDK v3.50.0 hosted fields, Safari 13.1.1, macOS 10.15.5 — any sense of when a fix might come?

Thanks for any help you can provide!

[crookedneighbor]

No ETA at this time.

[crookedneighbor]

OK, a little update on this. The reason this is happening is because Apple added a restriction in Safari 13 to block input focus unless it's triggered by a user action.

Normally, this is fine, you'd just need to only trigger input.focus() as a result of a click/keyboard event or other user action.

However, in this case, the user action of tabbing into the field is happening on the parent page, which means that by the time the focus method is fired inside the iframe, Safari can't detect that it was a user action that prompted the focus call, so Safari does not allow the input to be focussed.

We're brainstorming solutions for this, but unless Apple reverts the change or adds some avenue to allow this, I don't see a way to get around this behavior.

[crookedneighbor]

To clarify further, this is what's happening:

1. On the parent page, you tab to the first hosted fields iframe
2. The body of the iframe has focus, an event fires inside the iframe to trigger a focus on the input inside the iframe
3. On other browsers, without this user action restriction, the input is focussed immediately. In Safari, it ignores the call to focus and a second tab action is required, which moves the focus from the body element to the only other focusable element (the input)

[vivek-gapps]

Any update on this?

[crookedneighbor]

Unfortunately no, there is no way around this browser restriction. We're attempting to reach out to the Safari developers to see if there's a work around we can implement.