UA sniffing for iOS 10

Here’s the problem:

1. User focuses on text box
2. On-screen keyboard shows
3. User types some letters
4. Suggestions display beneath text box
5. User hides the keyboard
6. Suggestions hide before the user had a chance to select one by tapping one of them.

#6 is the problem: when the user hides the on-screen keyboard, the blur event fires on the textbox, in iOS 10. I don’t believe any other device does this including earlier versions of iOS.

I wonder if we can fix this by the approach we take to building this component.

Currently, the Javascript listens for the text box blur event and hides the suggestion list.

Here’s a very early thought of mine…

Don’t hide the suggestions on blur. Instead hide the suggestions when the user presses the tab key.

But what about clicking/tapping elsewhere on the page? In this case we should also hide the suggestions.

@tvararu raised concerns with listening to events that are outside of the components segment of the Document Tree.

I don’t share this concern. This is the nature of developing Javascript components in the browser. It might also be that a component listens to load/scroll/resize events at the window/document/body level, for example.

As long as a component does not stop propagation/bubbling then this is, in my book, absolutely no problem.

Raising this here to open up the discussion. Critique welcomed.

[tvararu]

Thanks for raising this @adamsilver and for presenting both solutions. 👍

You are correct that the UA sniffing is there to prevent closing the typeahead menu when iOS 10 users close their on-screen keyboard, and that iOS 10 Safari is unique in this behaviour.

You are correct that an alternative solution is to not rely on the “blur” event, and instead capture every expected interaction that the user can perform that will move focus away from the typeahead. Effectively reimplementing “blur.”

Here’s how I think the two stack against each other.

UA sniffing

Pros:

• Easy to implement / only changes branching code paths for one category of devices
• Recognises that the behaviour is non-standard

Cons:

• Widely recognised as a poorer alternative to feature detection or progressive enhancement

Reimplement blur

Pros:

• Uses recommended technologies only

Cons:

• More difficult to implement (tab, click, what are all the ways a user can blur something?)
• Makes the non-standard behaviour a significant part of the way the typeahead works with multiple new code paths
• Breaks encapsulation by polluting the window object with additional event listeners (and no easy way to delegate for multiple instances)

---

Happy to amend these with more input.

[tvararu]

@adamsilver It think would be interesting to try out the button pattern.

Has a bug been raised for iOS10?

Probably not, I haven’t at least.

It’s a difficult trade either way. At the very least, I wanted to offer up an alternative.

Agree, and your input has been and is valuable! 👍