API test WebKit.RequestTextInputContext fails on iOS
authortimothy_horton@apple.com <timothy_horton@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Tue, 12 Mar 2019 01:53:58 +0000 (01:53 +0000)
committertimothy_horton@apple.com <timothy_horton@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Tue, 12 Mar 2019 01:53:58 +0000 (01:53 +0000)
commit85349505358f5d44728b1c67ddbf46355c80e27a
treee82c9b14ac746762305386e3e5c3cac752c63d80
parent020db3fd5869ce4cce7c1dc34d27c408303a670c
API test WebKit.RequestTextInputContext fails on iOS
https://bugs.webkit.org/show_bug.cgi?id=195585

Reviewed by Wenson Hsieh and Simon Fraser.

Source/WebKit:

* UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView _convertRectFromRootViewCoordinates:]):
(-[WKWebView _convertRectToRootViewCoordinates:]):
(-[WKWebView _requestTextInputContextsInRect:completionHandler:]):
(-[WKWebView _focusTextInputContext:completionHandler:]):
* WebProcess/WebPage/WebPage.cpp:
(WebKit::elementRectInRootViewCoordinates):
(WebKit::WebPage::textInputContextsInRect):
(WebKit::elementRectInWindowCoordinates): Deleted.
Text input context SPI should be in terms of WKWebView coordinates,
for consistency's sake. This is a bit irritating; WebPage(Proxy) continue
to operate in "root view" coordinates, which means different things
depending on if delegatesScrolling is true or not. So, WKWebView does
the conversion, re-creating objects as needed.

Tools:

* TestWebKitAPI/Tests/WebKitCocoa/RequestTextInputContext.mm:
(applyStyle):
(TEST):
Add a viewport, so that the coordinates match up on iOS.
Scroll by moving the UIScrollView's contentOffset.

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@242762 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/WebKit/ChangeLog
Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm
Source/WebKit/WebProcess/WebPage/WebPage.cpp
Tools/ChangeLog
Tools/TestWebKitAPI/Tests/WebKitCocoa/RequestTextInputContext.mm