Title: [254755] trunk/Source/WebKit
- Revision
- 254755
- Author
- dba...@webkit.org
- Date
- 2020-01-17 10:59:57 -0800 (Fri, 17 Jan 2020)
Log Message
[iOS] Focusing editable element with WebPage::selectPositionAtPoint() does not bring up keyboard
https://bugs.webkit.org/show_bug.cgi?id=206385
<rdar://problem/57414380>
Reviewed by Wenson Hsieh.
Update the view's state to indicate that the user is performing an interaction for the scope of
WebPage::selectPositionAtPoint(). This permits WebKit to show the keyboard if selecting the
position causes a change in focus (say, the point is inside an unfocused text field).
We likely should do a similar change for all other WebKit IPIs that perform a WebCore::EUserTriggered::UserTriggered
tagged selection change though the callers should be audited to ensure they weren't accidentally
depending on the existing behavior that prevents such selections from bringing up the keyboard.
For now, I only fix WebPage::selectPositionAtPoint() as I've audited that all callers expect it
to bring up the keyboard, if needed.
* WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::selectPositionAtPoint):
Modified Paths
Diff
Modified: trunk/Source/WebKit/ChangeLog (254754 => 254755)
--- trunk/Source/WebKit/ChangeLog 2020-01-17 18:52:59 UTC (rev 254754)
+++ trunk/Source/WebKit/ChangeLog 2020-01-17 18:59:57 UTC (rev 254755)
@@ -1,3 +1,24 @@
+2020-01-17 Daniel Bates <daba...@apple.com>
+
+ [iOS] Focusing editable element with WebPage::selectPositionAtPoint() does not bring up keyboard
+ https://bugs.webkit.org/show_bug.cgi?id=206385
+ <rdar://problem/57414380>
+
+ Reviewed by Wenson Hsieh.
+
+ Update the view's state to indicate that the user is performing an interaction for the scope of
+ WebPage::selectPositionAtPoint(). This permits WebKit to show the keyboard if selecting the
+ position causes a change in focus (say, the point is inside an unfocused text field).
+
+ We likely should do a similar change for all other WebKit IPIs that perform a WebCore::EUserTriggered::UserTriggered
+ tagged selection change though the callers should be audited to ensure they weren't accidentally
+ depending on the existing behavior that prevents such selections from bringing up the keyboard.
+ For now, I only fix WebPage::selectPositionAtPoint() as I've audited that all callers expect it
+ to bring up the keyboard, if needed.
+
+ * WebProcess/WebPage/ios/WebPageIOS.mm:
+ (WebKit::WebPage::selectPositionAtPoint):
+
2020-01-17 Adrian Perez de Castro <ape...@igalia.com>
Fix various non-unified build issues introduced since r254327
Modified: trunk/Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm (254754 => 254755)
--- trunk/Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm 2020-01-17 18:52:59 UTC (rev 254754)
+++ trunk/Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm 2020-01-17 18:59:57 UTC (rev 254755)
@@ -2008,6 +2008,8 @@
void WebPage::selectPositionAtPoint(const WebCore::IntPoint& point, bool isInteractingWithFocusedElement, CallbackID callbackID)
{
+ SetForScope<bool> userIsInteractingChange { m_userIsInteracting, true };
+
auto& frame = m_page->focusController().focusedOrMainFrame();
VisiblePosition position = visiblePositionInFocusedNodeForPoint(frame, point, isInteractingWithFocusedElement);
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
