[UIWebView/WKWebView] Page shouldn't (always) scroll when keyboard is opened -- add configuration switch
| Originator: | radexpl | ||
| Number: | rdar://27762788 | Date Originated: | 09-Aug-2016 11:51 AM |
| Status: | Open | Resolved: | |
| Product: | iOS SDK | Product Version: | |
| Classification: | Enhancement | Reproducible: | Not Applicable |
Summary:
With UIWebView, when an <input> is tapped, and the keyboard is opened, the entire page (the whole contents of the web view) scroll so that the input becomes centered on the screen.
This is *good* in cases where the input is in a scrolling <body> — e.g. a form on a simple website. However, this isn’t always desirable, when a website or web app adds fixed interface elements (such as nav bars stuck to the top of the viewport), when the <input> is not on the main <body> but contained in a separate scroll view (i.e. <div> with `-webkit-overflow-scroll: touch` setting), or when an app uses a web view fragment for auxiliary UI and requires more control over how the keyboard and scroll views behave.
Test case:
Please see the attached test case project and screenshots for one example where this behavior is problematic. When you open the project in a simulator, you can see that the web page has a nav bar fixed to the top, and a separate scroll view (that’s not <body>) below.
Before you tap on anything, you should see the page as <BeforeKeyboard.png>.
But then after you tap, you’ll see <AfterKeyboard.png>. This isn’t desirable. The top bar should remain fixed to the top of the viewport, irrespective of the keyboard behavior.
Proposed solution:
After using web views on iOS for years, I see that in different cases, different keyboard/scrolling behaviors are desirable. I suggest that there should be a configuration switch on UIWebView and WKWebView with following options:
enum KeyboardScrollBehavior {
case scroll // this is the current behavior and should remain default. However, I consider it a bug that the whole page (web view’s whole scroll view) scrolls when the input is contained within a HTML scroll view. Whenever possible, only the inner scroll view should scroll, not the whole page
case none // equivalent to behavior of native UITextFields in UIScrollViews. Nothing happens after keyboard is opened — the keyboard covers part of the web view port, and it’s programmer’s responsibility to offset the scroll view so that the input becomes visible and properly positioned on the screen
case resizeViewport // when keyboard is opened, the web view’s view port is resized so that it covers the space *above* the keyboard. This way, the whole web view remains visible on the screen. Similar to `.none`, no scrolling occurs, and it’s programmer’s responsibility to change scroll view’s offset
}
Alternatively, or additionally, it would be desirable if some of these options were possible to set as CSS or HTML attributes. This way, website authors could ensure that their web app appears properly in Safari as well.
Comments
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!