Open Radar

 
Summary:

With UIWebView and WKWebView alike, opening an input causes the keyboard to open with a web input accessory view — the previous/next buttons (equivalent of Tab/Shift+Tab — navigation between form fields), and the “Done” button for closing the keyboard.

This is desirable in some cases — when you are, in fact, navigating through a form. But when you’re not, the accessory bar is only a nuisance, as it takes up valuable space on an iPhone, and contains navigation buttons which are useless if the input is not part of a form.

It should be possible to programmatically disable the accessory view.

It would also be of great use for developers taking advantage of web view fragments for auxiliary UI of native apps to be able to set *their own* accessory bar above the keyboard.

Proposed solution:

For merely disabling the accessory bar, a HTML/CSS attribute solution would be desirable, so that the attribute was also respected in Safari. For example:

<input -apple-accessory-bar=“none”>

For setting a custom accessory bar, a solution similar to 3D Touch support in WKWebView in iOS 10 could be used.

On WKUIDelegate and an equivalent in UIWebView, a delegate method such as:

func webView(WKWebView, accessoryViewForInput: WKInputElementInfo) → WKAccessoryView

… could be used. A second delegate method could be added to configure UITextInputAssistantItem on iPad.