When the iPhone keyboard is up, sometimes we never commit a stable update and re...
authorsimon.fraser@apple.com <simon.fraser@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Sat, 9 Dec 2017 00:00:09 +0000 (00:00 +0000)
committersimon.fraser@apple.com <simon.fraser@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Sat, 9 Dec 2017 00:00:09 +0000 (00:00 +0000)
commit343321d2cb6ce9688b2da1ca73e8d327e98fbf81
tree086d01ab666b76433ed516acd4c6178ee360d17c
parent5c711d4f53b8e5d0d97a66a7a908796588d264ad
When the iPhone keyboard is up, sometimes we never commit a stable update and re-show the caret
https://bugs.webkit.org/show_bug.cgi?id=180498

Reviewed by Tim Horton.

Source/WebKit:

When the keyboard is showing, we would think that the page was in a rubber-banding state
because contentOffsetBoundedInValidRange() would always clamp the content offset to a different
value.

This happened because scrollView.contentInset don't change when the keyboard is showing,
but UIKit actually consults scrollView.adjustedContentInset, which does. If we use
scrollView.adjustedContentInset in this computation, we'll get a correct answer.

Also rewrote the clamping logic to be more similar to what UIKit does internally when computing
min/max content offset.

* UIProcess/API/Cocoa/WKWebView.mm:
(contentOffsetBoundedInValidRange):

LayoutTests:

Test that completes once a stable update is received after showing the keyboard.

* fast/visual-viewport/ios/stable-update-with-keyboard-expected.txt: Added.
* fast/visual-viewport/ios/stable-update-with-keyboard.html: Added.

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@225714 268f45cc-cd09-0410-ab3c-d52691b4dbfc
LayoutTests/ChangeLog
LayoutTests/fast/visual-viewport/ios/stable-update-with-keyboard-expected.txt [new file with mode: 0644]
LayoutTests/fast/visual-viewport/ios/stable-update-with-keyboard.html [new file with mode: 0644]
Source/WebKit/ChangeLog
Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm