inputAccessoryViews should respect safe area inset with external keyboard on iPhone X

Originator:agiletortoise
Number:rdar://34411433 Date Originated:
Status:Open Resolved:
Product:iOS + SDK Product Version:Xcode Version 9.0 (9A235)
Classification:Bug - UI/Usability Reproducible:Always
 
Area:
UIKit

Summary:

If a UIResponder view (text field, text view, etc.) provides an inputAccessoryView and an external keyboard is attached, the inputAccessoryView is drawn by the system pinned to the bottom of the screen and does not respect the safe area insets of the current context.

This is a noticeable problem on the new iPhone X, where the input accessory view is clipped by and conflicts with the space reserved for the home button swipe.

Steps to Reproduce:

Launch attached sample project in iPhone X simulator, hide on-screen keyboard if visible.

Expected Results:

When on-screen keyboard is hidden due to attached external keyboard (or CMD-K in Simulator), the input accessory view should be pinned to the bottom of the current context's safe area insets, not the bottom of the screen to avoid conflicts with home button area on iPhone X.

Actual Results:

Input accessory view (red background) maintains it's 44.0pt height pinned to bottom of screen behind home button area.

Version/Build:

Xcode Version 9.0 (9A235) + Simulator.  No hardware available to test at this time.

Comments

Apple Response

Engineering has provided the following feedback regarding this issue: It’s your responsibility to respect the input accessory view’s safeAreaInsets. We designed it this way so developers could provide a background view (i.e., see Safari’s Find on Page input accessory view) and lay out the content view with respect to safeAreaInsets. This is fairly straightforward to accomplish. Have a view hierarchy where you have a container view and a content view. The container view can have a background color or a background view that encompasses its entire bounds, and it lays out it’s content view based on safeAreaInsets. If you’re using autolayout, this is as simple as setting the content view’s bottomAnchor to be equal to it’s superview’s safeAreaLayoutGuide.

By agiletortoise at Oct. 5, 2017, 3:23 p.m. (reply...)

I confirm what @tolar says. The input accessory view's layoutMarginsGuide and safeAreaLayoutGuide have the expected value, i.e. they account for the home button area when the keyboard is not visible and they dont when it is. Tested in the simulator.

I do not think there is a bug, we just have to be careful to use the right anchors, like everywhere else.

By alexandre.bintz at Oct. 1, 2017, 8:04 a.m. (reply...)

I was able to resolve this on my end by using layout margins guide instead of the input accessory view's own top/bottom anchors

By tolar at Sept. 27, 2017, 9:47 p.m. (reply...)

here's my similar bug report https://openradar.appspot.com/34694827 fwiw

By tolar at Sept. 27, 2017, 8:58 p.m. (reply...)

Hi!

I was curious if you'd heard back from Apple on this one. thanks!

By tolar at Sept. 27, 2017, 8:30 p.m. (reply...)

Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!