autofocus: not focusing input on ios 10

[lionelB]

Actual Behavior:

• What is the issue? * md-autofocus didn't focus input element, only add a css md-autofocus class
• What is the expected behavior? Input should receive the focus

CodePen (or steps to reproduce the issue): *

• http://codepen.io/lionelB/full/ZBvNBa

Angular Versions: *

• Angular Version: 1.5.9
• Angular Material Version: 1.1.1

Additional Information:

• Browser Type: * Mobile safari
• Browser Version: * latest
• OS: * IOS 10
• Stack Traces:

[lionelB]

This was working as expected is IOS9

[clshortfuse]

Safari on iOS prevents elements from receiving focus if no user interaction triggered the JavaScript code. It's either a timing issue or fastClick is causing issues.

[clshortfuse]

@devversion I believe this may be either gesture related and/or event sequencing. I believe iOS doesn't allow focus on items unless there's an attached touch gesture.

[kevin-j-f]

We're getting the same issue on Angular 1.5.3 with Angular Material 1.1.4. We upgraded material to 1.1.18 and it seems to fix the issue with inputs, but then has the same issue with dropdowns. This only started happening on iOS 12.2 for us, all earlier versions work

[kevin-j-f]

https://material.angularjs.org/latest/api/service/$mdGestureProvider

Found out by setting $mdGestureProvider.skipClickHijack(), it fixes the issue. There must be a bug with the click hijacking logic.

[Splaktar]

@kevin-j-f $mdGestureProvider.skipClickHijack() can certainly help with a lot of gesture issues. Setting that fixed it for you in 1.1.4 or it fixed the dropdown issue in 1.1.18?

[clshortfuse]

This is over two years old, but I did write some custom heuristics to safely skip click hijack if it's not needed:

#8996 (comment)

[kevin-j-f]

@Splaktar

We encountered the issue with input's not being focusable until long press in 1.1.4. Then we upgraded to 1.1.18 and that fixed inputs, but then dropdown's started having the same issue where they would open and then immediately close. We reverted to 1.1.4 and tried to hack things to make it work. We eventually found that skipClickHijack() completely fixed it in 1.1.4, so we didn't upgrade since it's kind of a big app and didn't want to deal with any issues that might have come up from jumping 14 versions.

I imagine that it would fix the dropdown in 1.1.18 after doing some more reading on the issues, but I can't confirm. I was mostly posting in case anyone else was having the issue, we've been searching for a week+ and couldn't find any info, or if it might help someone debug why it causes an issue. Our issues seem to be solved by just turning off click jacking though

[Splaktar]

I just verified that this is fixed in Safari 12 (iOS 12.4.1 tested) using this updated CodePen. This is without the need to call skipClickHijack(). It may also have been fixed in iOS 11.

[welljsjs]

Ah, no, sorry, the example you provided does not work for me. The keyboard does not show up on iOS 13.1.3.

[clshortfuse]

From my own testing, building a solution from scratch, in order for a dialog to show up, focus on an input, and have the keyboard open up:

• it must all be done within the CLICK event function. You can't delay with setTimeout, or requestAnimationFrame.
• the input element must be visible. It won't work if the element is not in the viewport bounds (easy for dialogs, harder for tabs)

So, basically, you need to make sure the element dialog and input are visible with synchronous changes to the DOM before the event is over. That means a timeout in the click highjacker won't work. Also, you can't wait for a digest loop either. Nor can you use a promise.

That said, the codepen provided does work for me on 13.1.3, but sometimes it didn't trigger, and I'm not sure why. If there's a fault somewhere, it would be in one of two criteria I described not being met.

[Splaktar]

I just tested on iPadOS 13.2 with Safari and Chrome and the input was auto focused in both cases (class applied), but the keyboard does not consistently open in the CodePen editor. I think that this is a CodePen issue.

When testing in the debug view on both browsers, the input was focused and the keyboard appeared both times.